4 ms·

I consider Tracy the state of the art for profiling C++ applications. It’s straightforward to integrate, toggle, gather data, analyze, and respond. It’s also o

I consider Tracy the state of the art for profiling C++ applications. It’s straightforward to integrate, toggle, gather data, analyze, and respond. It’s also open source, but rivals any product you’d have to pay for: https://github.com/wolfpld/tracy https://github.com/wolfpld/tracy

deleted 2y ago
[deleted]
Veserv 2y ago
Looks fine, but it does not look like there is a automatic full function entry/exit trace, just sampling. The real benefit is when you do not even need to insert manual instrumentation points, you just hit run and you get a full system trace. How well does the visualizer handle multi-TB traces? Usually pretty uncommon, but a 10-100 GB is not that hard to produce when doing full tracing.
- jms55 2y ago
  Of note is that tracy is aimed at games, where sampling is often too expensive and not fine-grained enough. Hence the manual instrumenting. For the Bevy game engine, we automatically insert tracy spans for each ECS system. In practice, users can just compile with the tracy feature enabled, and get a rough but very usable overview of which part of their game is taking a long time on the CPU.
  - Veserv 2y ago
    I was talking about automatic instrumentation of every single function call by default. No manual instrumentation needed because everything is already instrumented. To be fair, you do still want some manual instrumentation to correlate higher level things, but full trace everywhere answers most questions. You also want to be able to manually suppress calls for small functions since that can be performance relevant or distorting, but the point is “default on, manual off” over “default off, manual on”.
    - andersa 2y ago
      This would be unbelievably inefficient, game engines will be running hundreds of millions of functions per second. And if the code runs 10x slower with the trace active, then it's no longer sensible. We use sampling for the cases where this level of detail is needed as it has lower overhead. What use case did you find this useful for?
      - Veserv 2y ago
        No, it is quite reasonable with efficient implementation. 10-50% overhead or so depending on function size distribution (since it is small fixed overhead per call, smaller functions result in a greater fraction of overhead). 10x for just function entry/exit recording would be grotesquely inefficient. You can do inefficient time travel debugging recording for less than that. You do need to allocate a ton of memory for the recording buffer to record sizable amounts of trace data. GB per core-second of trace or so (ring buffer so you get to see the last N seconds, not you need to run for less than N seconds) but that is fine during development on normal dev machines. It is useful for everything. Why would you not want full traces for everything? It is amazing. We use it for everything internally where I work. Or rather, it is part of it. We actually prefer full time travel debugging during development and automated testing (again, overhead is low enough) but it is not available for everything. So sometimes we are stuck with just traces.
      - donadigo 2y ago
        Every function would be pretty overkill, but you can automatically install instrumentation on functions on demand or with a pre-determined user selection. You can even instrument on a line basis if your instrumentation is cheap enough. I've experimented with this in a VS extension I'm developing and I could easily browse through a non-trivial game codebase without causing noticeable performance overhead [1]. In the demo, the instrumentation is auto-installed on all functions within the file you opened. Obviously, this is just one project I was testing on but it shows that this type of tracing is feasible. [1] https://www.youtube.com/watch?v=3PnVG49SFmU https://www.youtube.com/watch?v=3PnVG49SFmU
    - deleted 2y ago
      [deleted]
rerdavies 2y ago
Alas, not for Linux. I've been using the unloved and mostly abandoned (and mostly awful) google perf tools on Linux. :-(
- jchw 2y ago
  Hmm? I haven't used Tracy yet but the demo trace they show at the URL linked on GitHub[1] sure looks like a trace from an application running on Linux. The documentation[2] also seems to reference what you need to run it on Linux, and the NixOS derivation[3] also suggests it runs on at least Linux and macOS, and I was able to run several of the binaries including the UI and capture binary. I still hesitate to doubt you on this because I haven't figured out how one is supposed to actually use it but it surely seems to support Linux. (I will definitely find a use for this, it looks amazing.) [1]: https://tracy.nereid.pl/ https://tracy.nereid.pl/ [2]: https://github.com/wolfpld/tracy/releases/latest/download/tracy.pdf https://github.com/wolfpld/tracy/releases/latest/download/tr... [3]: https://github.com/NixOS/nixpkgs/blob/nixos-24.05/pkgs/development/tools/tracy/default.nix#L106 https://github.com/NixOS/nixpkgs/blob/nixos-24.05/pkgs/devel...
- HellsMaddy 2y ago
  Tracy works fine on Linux! Just used it today.
  - rerdavies 2y ago
    OK. Thanks for straightening me out. I saw the .msi, but no linux packages. I will definitely check it out!
    - las_balas_tres 2y ago
      That github repo contains the sources. You can also compile tracy by cloning the repo.
- dkersten 2y ago
  I’ve used Tracy on Linux about two months ago. Works fine.

deleted 2y ago

[deleted]

Veserv 2y ago

Looks fine, but it does not look like there is a automatic full function entry/exit trace, just sampling. The real benefit is when you do not even need to insert manual instrumentation points, you just hit run and you get a full system trace. How well does the visualizer handle multi-TB traces? Usually pretty uncommon, but a 10-100 GB is not that hard to produce when doing full tracing.

jms55 2y ago
Of note is that tracy is aimed at games, where sampling is often too expensive and not fine-grained enough. Hence the manual instrumenting. For the Bevy game engine, we automatically insert tracy spans for each ECS system. In practice, users can just compile with the tracy feature enabled, and get a rough but very usable overview of which part of their game is taking a long time on the CPU.
- Veserv 2y ago
  I was talking about automatic instrumentation of every single function call by default. No manual instrumentation needed because everything is already instrumented. To be fair, you do still want some manual instrumentation to correlate higher level things, but full trace everywhere answers most questions. You also want to be able to manually suppress calls for small functions since that can be performance relevant or distorting, but the point is “default on, manual off” over “default off, manual on”.
  - andersa 2y ago
    This would be unbelievably inefficient, game engines will be running hundreds of millions of functions per second. And if the code runs 10x slower with the trace active, then it's no longer sensible. We use sampling for the cases where this level of detail is needed as it has lower overhead. What use case did you find this useful for?
    - Veserv 2y ago
      No, it is quite reasonable with efficient implementation. 10-50% overhead or so depending on function size distribution (since it is small fixed overhead per call, smaller functions result in a greater fraction of overhead). 10x for just function entry/exit recording would be grotesquely inefficient. You can do inefficient time travel debugging recording for less than that. You do need to allocate a ton of memory for the recording buffer to record sizable amounts of trace data. GB per core-second of trace or so (ring buffer so you get to see the last N seconds, not you need to run for less than N seconds) but that is fine during development on normal dev machines. It is useful for everything. Why would you not want full traces for everything? It is amazing. We use it for everything internally where I work. Or rather, it is part of it. We actually prefer full time travel debugging during development and automated testing (again, overhead is low enough) but it is not available for everything. So sometimes we are stuck with just traces.
    - donadigo 2y ago
      Every function would be pretty overkill, but you can automatically install instrumentation on functions on demand or with a pre-determined user selection. You can even instrument on a line basis if your instrumentation is cheap enough. I've experimented with this in a VS extension I'm developing and I could easily browse through a non-trivial game codebase without causing noticeable performance overhead [1]. In the demo, the instrumentation is auto-installed on all functions within the file you opened. Obviously, this is just one project I was testing on but it shows that this type of tracing is feasible. [1] https://www.youtube.com/watch?v=3PnVG49SFmU https://www.youtube.com/watch?v=3PnVG49SFmU
  - deleted 2y ago
    [deleted]

rerdavies 2y ago

Alas, not for Linux. I've been using the unloved and mostly abandoned (and mostly awful) google perf tools on Linux. :-(

jchw 2y ago
Hmm? I haven't used Tracy yet but the demo trace they show at the URL linked on GitHub[1] sure looks like a trace from an application running on Linux. The documentation[2] also seems to reference what you need to run it on Linux, and the NixOS derivation[3] also suggests it runs on at least Linux and macOS, and I was able to run several of the binaries including the UI and capture binary. I still hesitate to doubt you on this because I haven't figured out how one is supposed to actually use it but it surely seems to support Linux. (I will definitely find a use for this, it looks amazing.) [1]: https://tracy.nereid.pl/ https://tracy.nereid.pl/ [2]: https://github.com/wolfpld/tracy/releases/latest/download/tracy.pdf https://github.com/wolfpld/tracy/releases/latest/download/tr... [3]: https://github.com/NixOS/nixpkgs/blob/nixos-24.05/pkgs/development/tools/tracy/default.nix#L106 https://github.com/NixOS/nixpkgs/blob/nixos-24.05/pkgs/devel...
HellsMaddy 2y ago
Tracy works fine on Linux! Just used it today.
- rerdavies 2y ago
  OK. Thanks for straightening me out. I saw the .msi, but no linux packages. I will definitely check it out!
  - las_balas_tres 2y ago
    That github repo contains the sources. You can also compile tracy by cloning the repo.
dkersten 2y ago
I’ve used Tracy on Linux about two months ago. Works fine.