heaptrack VS pprof-rs

If we are talking replacing the libc allocator, then something like heaptrack is worth mentioning.

https://github.com/KDE/heaptrack

For accurate memory usage I prefer a memory profiler that overrides malloc and friends instead of the ones that probe the OS at regular intervals. You won't find memory spikes with the latter. Try heaptrack on Linux. I haven't found a good one for Windows yet.

I know it is not a profiler, but it is so criminally underrated that I decided to share it: https://github.com/KDE/heaptrack

If none of the above helps - I recommend heaptrack as a tool for tracking down your memory usage.

> memory leaks. It's surprisingly hard to find an easy to use memory leak detection tool.

I can vouch for heaptrack[1] nowadays, although it's pretty much Linux only. It's under the umbrella of KDE, but a heaptrack trace only requires a CLI app, and there is a nice Qt viewer to analyse the memory consumption.

It tracks the memory utilization at the level of malloc'd/free'd bytes. It's fine if your memory leak or other memory utilization problem is on this level. Recently I dealt with an issue, where increasing memory utilization was caused by fragmentation within the allocator. This didn't show up in heaptrack as an increasing memory utilization, but heaptrack still pointed out where most of the temporary allocations happened, leading to the culprit of the fragmentation.

[1] https://github.com/KDE/heaptrack

This is probably what you are looking for https://github.com/KDE/heaptrack

When I had this kind problems (heap related) I always use heaptrack. Take a look here for the details: https://github.com/KDE/heaptrack

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.