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.
Author here. The interesting point was that RSS is much too large with glibc malloc + RocksDB/MyRocks. The performance differences aren't a big deal, but OOM because RSS is 2X or 3X larger than it should be is a big deal. Of course, that problem is workload specific, but RocksDB/MyRocks are a workload on which I focus.
I lurk on email lists for RocksDB and OOM from glibc malloc is a problem for users -- the solution is easy, use jemalloc or tcmalloc.
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.