Battle of the Mallocators
7 comments
·April 12, 2025fweimer
The post was written two days ago, but the allocator versions are between three and six years old.
Nowadays, there are at least two different versions of tcmalloc: the one from https://github.com/google/tcmalloc/ is newer (it has rseq support, for example), and the version bundled in https://github.com/gperftools/gperftools.
WalterGR
RSS = Resident Set Size. https://en.wikipedia.org/wiki/Resident_set_size
sweettea
Note also that, on Linux, RSS is not guaranteed to be accurate: "For making accounting scalable, RSS related information are handled in an asynchronous manner and the value may not be very precise." [1]
[1] https://www.kernel.org/doc/html/latest/filesystems/proc.html
ajross
Seems like there's no attention paid to documenting (or just discovering -- looks like the heaps in question were just the ones provided by their linux distro) the build and runtime configuration in use. There are a lot of hardening/tracing/robustness/shenaniganproofing features in modern heaps, and if you're going to make noise about a few percent of performance it's really important to be clear about exactly what the software you're measuring is doing.
To be blunt: my gut would say that glibc on typical distros is more hardened than default builds of alternative heap implementations, and if it's only off by a few percent it might well be the faster code if measured apples-to-apples.
stefantalpalaru
[dead]
Yes there is lots of evidence that jemalloc fares better in high concurrency applications.
Fun fact, jemalloc was the default allocator for rust but was dropped off and use default system allocator to have smaller binary size