3 ms·
we actually ended up with (new) tcmalloc. for us, tc was among the fastest in runtime while being very space efficient [0]. large rust application using far to
by skavi 9d ago
we actually ended up with (new) tcmalloc.
for us, tc was among the fastest in runtime while being very space efficient [0]. large rust application using far too many threads.
we’ve since also had great success with tc’s built in profiling tools.
[0]: https://news.ycombinator.com/item?id=47403847 https://news.ycombinator.com/item?id=47403847
- imp0cat 8d agoInteresting, is there an accompanying article? We've tried tcmalloc, too. I don't remember the exact details, but we basically ended using jemalloc because it was using way less memory. Same story with mimalloc - it usually provided a tiny bit more speed, but required more cpu and memory.
- skavi 8d agono article, sorry, grabbed the numbers from an old PR. to confirm, you were using tcmalloc from https://github.com/google/tcmalloc https://github.com/google/tcmalloc and not from https://github.com/gperftools/gperftools https://github.com/gperftools/gperftools, right? the latter is a lot worse iiuc.
- imp0cat 8d agoGood point. It was from the https://packages.debian.org/trixie/google-perftools https://packages.debian.org/trixie/google-perftools Debian package, which points to the gperftools project - so it was the worse one I guess.
- skavi 8d agoyeah that’s a common mistake when evaluating tcmalloc. gperftools tcmalloc diverged quite a while ago. doesn’t have a lot of the fancier features of modern tcmalloc [0]. [0]: https://github.com/google/tcmalloc/blob/master/docs/gperftools.md#differences https://github.com/google/tcmalloc/blob/master/docs/gperftoo...