pprof-rs VS samply

On top of others' specific recommendations, don't forget to profile! Tools like perf on Linux and pprof within Rust will tell you which functions are taking the most time.

https://github.com/tikv/pprof-rs: Seems to work nicely per se, but I cant seem to find any useful information in the flamegraph for my setting. I see mostly functions in std::thread but cant find the time it costs to render stuff or to do the actual computations which should be the most time consuming things. Not sure whether this is necessarily something wrong with pprof-rs, maybe I'm just bad at finding stuff in the flamegraph svg or bevys ECS is making this hard.

Have you looked into using pprof?

The library doesn't actually do any profiling (The profiler for Rust is pprof-rs: https://github.com/tikv/pprof-rs) but it's goal is to manage data returned by profilers (abstracted behind a Backend) and send this data to a Pyroscope Server (or exported to flamegraph, though this is being implemented in the commandline application).

The libunwind part is actually not related to overhead, this is just a nuance of the way that pprof-rs unwinds stack traces.

Regarding profilers, I really like samply. It doesn't require to modify source code, runs on Linux and macOS and automatically loads profiling data into Firefox Profiler UI.

I grabbed a quick profile using samply and noticed two things: Even in fast mode, the simulation only updates when the screen is redrawn, so its update frequency is limited by the refresh rate. And the simulation seems to mostly be bottle-necked by Vec reallocation, so re-using Vecs might help.

I ran across this when I found samply [0], a CLI sampling profiler. On samply's GitHub there's a link to a sample profile that opens in the Firefox Profiler and I was in awe at just how fast it is! Try dragging your mouse over the timeline for a second: https://share.firefox.dev/3j3PJoK

0: https://github.com/mstange/samply

IMHO, perf's decision to write whole stacks directly to the disk and unwinding them as a post-process is a really bad design. It wastes disk space, and as the author pointed out, it also has a lot of IO overhead.

As an alternative approach, https://github.com/mstange/samply processes data streamed from perf and unwinds it in realtime. The unwinding overhead is surprisingly low: it only takes around 1% of (single) CPU per CPU profiled. Solving the disk waste alone has been a tremendous improvement of profiling experience. As a bonus, the unwinding and symbolization works reliably while I frequently had postprocessing not terminating when using the perf CLI directly.

samply supports showing inline frames in call stacks. I find this makes a huge difference when profiling Rust.