bytehound VS heappy

I've found bytehound helpful for tracking memory leaks: https://github.com/koute/bytehound

Interesting approach. How is performance compared to something like https://github.com/koute/bytehound

https://github.com/koute/bytehound is another tool in this space to be aware of

Ot sure if it will fit your needs but maybe bytehound is worth looking into.

I had a great success recently with https://github.com/koute/bytehound/issues/86

Try using this: https://github.com/koute/bytehound

> But, for example, some runtime-related tools (most notably, heap profiling) are just absent — it’s hard to reflect on the runtime of the program if there’s no runtime!

Yeah; I felt that pain too.

I tried to write something to address some parts of the missing space. It's still in the early stages but you may be interested:

https://github.com/mkmik/heappy

I hate to be "that guy" too, but coming from somebody who really likes Rust and is using it more and more (also at $dayjob now) we must admit that Go tooling is one step ahead. CPU profiler, allocation and heap profiler, lock contention profiler. It all comes out of the box.

Yes you have cargo flamegraph for profiling locally and you now have pprof-rs to mimick Go's embedded pprof support. But allocation heap profiling is still something I struggle with.

I saw there was a pprof-rs PR with a heap profiler but there was some doubt as to whether it worked correctly; to get a feeling of how that approach would work but without having to fork pprof-rs I implemented the https://github.com/mkmik/heappy crate which I can use to produce memory allocation flamegraphs (using the same "go tool pprof" tooling!) in real code I run and figure out if it works in practice before pushing it upstream.

But stuff you give for granted like figuring out which structure accounts for most used memory, is very hard to achieve. The servo project uses an internal macro that help you trace the object sizes but it's hard to use outside the servo project.

The GC makes some things very easy, and it's not just about programmers not having to care about memory; it's also that the same reference tracing mechanism used to implement GC can be used to cheaply get profiling information.