RFC: Sequence Point feature

[slomp]

This is an experiment with adding "sequence point" instrumentation directives to Tracy.
The use case here is asynchronous compute chains/graphs, especially those driven by callbacks chains.

You'd use TracySeqCreate() to request a unique sequence identifier, and pass that id along to TarcySeqResume(id) and TracySeqSuspend(id) at each "continuation" scope. At the end of the processing, you'd TracySeqRetire(id) it. Later, in the profiler GUI, hovering over a sequenced zone would show arrows pointing to the previous and next sequence point zones.

In addition, if you right-click on a zone that belongs to a sequence point, there's the option to "flatten" it to a "virtual thread" in order to visualize it in isolation in the timeline.

Context: over the years, I managed to workaround just by using TRACY_FIBERS as a way to define "virtual threads", and then assigning each async compute chain to one such virtual thread.

Curious to know other people's opinion. There's a (vibe-coded) examples/seq to demonstrate the feature.

Screen.Recording.2026-05-28.at.11.11.11.AM.mp4

[Lectem]

Depending on the intended usage I had the following ideas and scope, and they all have their limitations. The main issue is: what granularity do we want

• Single id for the whole "pipeline":
  • Suitable for tracking things such as web requests, potentially across modules, executables, network, etc...
  • Doesn't allow to know who triggered what exactly, for example in fork-join scenarios. We can infer it, but it won't ever be precise
• Single Id per "dispatch" of work. When you start working on the same data but dispatch to another system, you get an new id, and the system notifies it grabbed the job via the id.
  • Allows to instrument any kind of synchronization
  • Granular
  • Requires graph analysis to get full pipeline, and might grab unrelated tasks (for example if a zone works on multiple inputs from different requests)
• Mixing both: You emit a new id per dispatch, but allow to track them per "context" to regroup them. Potentially in multiple contexts

[slomp]

Grouping makes a lot of sense. A very common use case for me (in fact, it's what inspired this experiment) is defining a number of "channels" to organize this sort of parallel continuations in virtual threads/timelines.

Concretely, there's a set number of "fiber names", and you'd instrument all sequence points of a given async task with the same fiber name. So, when an async task is created, it claims a fiber name, uses it through. Doing so ensures no two zones ever "intersect" in any given fiber timeline.

If we have support for grouping, you'd then be able to flatten all TracySeq'd zones that belong to the same group, and basically recreate the "TracyFiber"-equivalent behavior "on demand" from the UI. We could think about going one step further and consider adding more explicit directives to define and use "virtual threads" (fibers and sequence-points would just be specialized cases that build upon the virtual thread functionality).