Blog Post: (I want) A Better Rust Profiler

https://matklad.github.io/2021/02/10/a-better-profiler.html

8 Likes

I'm aware you'd be "happy with a Linux-only" solution so this might not fit you, but an OSX-only solution, cargo-instruments, which I used a year ago worked very well for me (without extra code added to it):

I wonder if there's such tools available that allow for all the textual info you mention and easy interactive exploration of the metrics.

I wonder how hard would be to add Rust to this one: GitHub - pyroscope-io/pyroscope: 🔥 Continuous Profiling Platform 🔥 Debug performance issues down to a single line of code

First, the profiler prints to stderr:

warning: run with `--release`
warning: add `debug=true` to Cargo.toml
warning: set `RUSTFLAGS="-Cforce-frame-pointers=yes"`

I wonder why not add a feature to enable this stuff, e.g. force-frame-pointers is unnecessary on x86-64, tectonic build.rs uses the cc crate (the details escape me on the cargo side so i am uncertain if this is set up correctly for profiling rust code),

The nature of the TeX engine that leads force-frame-pointers to such a severe performance degradation that it is worthwhile to avoid setting it, anyhow it seemed perhaps worth mentioning there is at least some scaffolding around for conditionally setting this in build.rs.

1 Like

Using DWARF unwind tables is much slower for unwinding than using frame pointers. In fact so much slower that it is not possible to do it in real time, thus requiring a copy of the stack to be included for each sample. If your call stack is relatively deep, parts of the backtrace will be missing. Even if you set the amount of copied stack space to 50k, which is the maximum for perf, there may still be frames missing. This happens for example when profiling rustc itself.