How should profiling new Swift Concurrency APIs look like?

[icanzilb]

EDIT: Please leave your feedback or ideas below in the comments.

---

There doesn't seem to be an Instrument to specifically debug the new Swift concurrency APIs so it seems that there is an opportunity to leverage TimelaneCore and build a Swift Concurrency specific wrapper.

On the other hand TimelaneCore is specifically build around subscriptions so that it nicely handles RxSwift, Combine, etc. Maybe it is better to create a new Swift Concurrency specific instrument that could track other things like groups and tasks?

I can imagine when debugging concurrent code I'd be interesting to see visually how many tasks are running concurrently, maybe what results they returned, for how long did a group run, things like this.

I think the best way to go about this is to gather some input from a wider group of developers.

[earltedly]

A few things I'd like to see off the top of my head

1. The various trees of threads I have created, their hierarchy, priorities and backtraces to each part of their life cycle
2. Insights into the new cooperative threading model - which threads are currently executing on which core, which ones are waiting
3. Visualising threads moving in and out of being active - perhaps stats on how much execution time a thread has had and counters on the state changes

[icanzilb]

@earltedly great ideas! It feels a bit challenging to provide such deep insight via a custom Instrument but I have the feeling we could make some of these work.

If I'm not wrong threads have identity so if a Timelane API wraps TaskGroup.async(...) we could map the start and end of each task and on which thread or threads did it end up executing (code can jump threads at every await so a single task can cross threads at will). I guess this could then allow also providing aggregate data as you say - total time of running tasks on a given thread, total duration of a task vs. active/suspended states, and more.

I'm afraid I can't think of a way (atm) that Timelane could wrap a code suspension and resume since these seem to be compiler features and not an API we could wrap. E.g. we can't have a wrapped version of await for the purpose of sending signposts to Instruments ... (right?)

I'm thinking if it could be possible at all to somehow wrap @sendable altogether - this could be a killer feature because all the Instruments data can be then automated.