Battle of the Mallocators

Seems like there&#x27;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 <i>lot</i> of hardening&#x2F;tracing&#x2F;robustness&#x2F;shenaniganproofing features in modern heaps, and if you&#x27;re going to make noise about a few percent of performance it&#x27;s really important to be clear about exactly what the software you&#x27;re measuring is doing.<p>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&#x27;s only off by a few percent it might well be the faster code if measured apples-to-apples.

Yes there is lots of evidence that jemalloc fares better in high concurrency applications.<p>Fun fact, jemalloc was the default allocator for rust but was dropped off and use default system allocator to have smaller binary size

The post was written two days ago, but the allocator versions are between three and six years old.<p>Nowadays, there are at least two different versions of tcmalloc: the one from <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;tcmalloc&#x2F;">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;tcmalloc&#x2F;</a> is newer (it has rseq support, for example), and the version bundled in <a href="https:&#x2F;&#x2F;github.com&#x2F;gperftools&#x2F;gperftools">https:&#x2F;&#x2F;github.com&#x2F;gperftools&#x2F;gperftools</a>.

RSS = Resident Set Size. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Resident_set_size" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Resident_set_size</a>

<a href="http:&#x2F;&#x2F;ithare.com&#x2F;testing-memory-allocators-ptmalloc2-tcmalloc-hoard-jemalloc-while-trying-to-simulate-real-world-loads&#x2F;" rel="nofollow">http:&#x2F;&#x2F;ithare.com&#x2F;testing-memory-allocators-ptmalloc2-tcmall...</a>