Wez Furlong 88c28b62c0 memory: implement our own tracking allocator ...

The re_memory crate was good for a first pass at implementing call stack
tracking, but unfortunately, it was symbolicating the stack traces in
the allocation path which had terrible performance implications.

This commit implements our own somewhat leaner and meaner version of
this functionality that defers resolving the call stack symbols until
the top callstacks are computed.

This makes things run faster than they would have when using re_memory.

Shedding re_memory also allows us to avoid pulling in the various other
dependencies that it pulled in that were otherwise unused, which makes
me feel even better about this.

This commit also improves the output of the summarize-memory tool to
make it clearer that we are uncertain about the full extent of the
sampled allocations: the stochastic sampling only nominally samples
every 64 of the medium-sized allocations. That means that the reported
total size for those may be 1/64 of what we printed previously.  We now
print the range of allocations and use a ~ character to indicate that
we're uncertain about the number of allocations that were made for those
sampled allocations.

2024-12-11 15:51:26 -07:00

..

src

memory: implement our own tracking allocator

2024-12-11 15:51:26 -07:00

Cargo.toml

memory: implement our own tracking allocator

2024-12-11 15:51:26 -07:00