Comparison with heaptrack?

[expenses]

It'd be nice to have a quick comparison in the readme about why you would want to use one or the other.

[jyn514]

I used bytehound because heaptrack was giving assertion failures:

heaptrack_interpret: /build/heaptrack-jcO0xN/heaptrack-1.1.0+20180922.gitf752536/src/util/linewriter.h:84: bool LineWriter::write(const char*, T ...) [with T = {const char*}]: Assertion `false && "message doesn't fit into buffer"' failed.

Not sure what bug it has, but bytehound works fine.

[jmerdich]

From experience, heaptrack has a fairly terrifying serializer/deserializer, and I'm not surprised something like that would happen with the long symbols that async rust has.

[dralley]

Also a comparison against DHAT / Massif (from Valgrind) and perhaps DHAT (the Rust library, which is different from the Valgrind one) would be useful.

This tool looks great but it's hard to understand which to prefer in what circumstances, especially when I only need to go debug memory leak issues once every 6 months (or less)

[Imberflur]

I recently had a chance to try both heaptrack and bytehound on a memory leak issue. Previously I have used heaptrack but this was my first time trying bytehound. Here are some observations from my experience:

• Some backtrace views in bytehound included line numbers which I did not see in heaptrack (at least for my case). (The flamegraph in bytehound does not include line numbers though afaict). In general, I had a better experience with the backtraces in bytehound.
• bytehound includes scripting capabilities for analysis which ended up being fairly useful even with just a few snippets taken from the introduction here https://koute.github.io/bytehound/memory_leak_analysis.html.
• Because I compiled bytehound I was able to easily include RUSTFLAGS="-C target-cpu=native", which potentially helped reduce profiling overhead.
• The profiling overhead from bytehound was very roughly ~1/3 of the overhead from heaptrack, but with occasional spikes (still less than the time taken by heaptrack). I did not attempt to get a precise comparison though.
• Profile data files from bytehound seem to be an order of magnitude larger than those from heaptrack. I don't know if the ones from heaptrack are not portable or if there is some reason for this difference.
• The bytehound server used for viewing/analyzing data can use a lot of RAM when starting up.
• There is an option to export data for viewing in heaptrack's GUI, although I did not try it.