Having written similar tools like this in the past I pretty much exclusively use Tracy nowadays and let all my old stuff rot. The UI is snappy/fluid even with a tremendous amount of events, instrumentation is rich (zones/plots/memory tracking with timing, GPU events, logging, etc) and sampling is robust across all major platforms (Windows/Android/Linux/Mac) and the disassembly/analysis is as solid as most vendor tools. If wanting to integrate/use any tool like this I strongly recommend Tracy and then occasionally using vendor tooling where better (but platform/hardware limited). Having a single swiss-army knife perf tool makes it much easier for most of the team to learn and use it and leave the specialized knowledge of vendor tooling to those who need it.
There's also superluminal (https://superluminal.eu/), but it's closed source/paid - wolfpld (the Tracy author) is responsive and there's a decent set of contributors so switching to a black box on a part of the engineering process that is designed to avoid black boxes isn't very enticing. It also is sketchy/misleading about saying things like "Superluminal is the only sampling profiler that displays the profiling data in a visual UI." which is a big turn-off for someone who's been using/building tools like that for decades :)
Tracy has been around for a while. It works well for Rust.
It's intended for frame-oriented applications, where you're looking for bottlenecks which delay a frame. Unlike most profilers, where you're concerned about average time, Tracy is most useful when you're concerned about worst-case time. You can find the slowest frame and zoom way in to see what went wrong.
The program has to be instrumented. You add
profiling::finish_frame!()
to be called once per frame. Around scopes of interest, you add
profiling::scope!("Event");
then run and look at the result, which is a zoomable timeline. If a profiling scope is using a lot of time, you go back in and add more "scope" calls around subsections of that scope. This gets you more rows on the profile graph and more detail about where time is going.
> Unlike most profilers, where you're concerned about average time, Tracy is most useful when you're concerned about worst-case time.
Tracy is also really useful for measuring average time of functions! It gives you the average / median execution time of each function along with a a nice distribution graph, which is far better than any other profiler I've used so far. You can even compare the execution time / distribution between two profiling results, which is really handy when you're doing any optimization work.
I have used Tracy to improve the performance of a latency sensitive application. The main advantage of this tool, in comparison to something like the Visual Studio profiler, is the fact that it can highlight the inter thread dependencies and synchronization between the threads. The other main feature, in my opinion, is the statistical tab that is associated to the recorded events: it can show the statistical distribution of the duration of all the invocations of functions and it allows to identify patterns in the performance of the application. Furthermore, a table can be used to sort the invocations of the functions and quickly jump to the point in time when the sample was recorded.
Other notable tools that implement a functionality similar to what is provided by Tracy are Optick https://github.com/bombomby/optick and Intel VTune (sadly specific to only Intel processors) in the Threading analysis.
One neat feature is that you can import Chrome traces. Instrument with normal JS perf marker API! The Tracy UI is just so much better for viewing them.
That said, the title confuses me:
I am always thinking of Tracy as an instrumented profiler, not a sampling profiler. I only ever used it as instrumented.
Sampling: Profiler takes stack samples of any code, at fixed frequency, gives you rough hotspots.
Instrumented: Report sample points to profiler. Requires putting profiling point into the code to be analyzed.
There's also superluminal (https://superluminal.eu/), but it's closed source/paid - wolfpld (the Tracy author) is responsive and there's a decent set of contributors so switching to a black box on a part of the engineering process that is designed to avoid black boxes isn't very enticing. It also is sketchy/misleading about saying things like "Superluminal is the only sampling profiler that displays the profiling data in a visual UI." which is a big turn-off for someone who's been using/building tools like that for decades :)