Glibc Enables a Per-Thread Cache for Malloc – Big Performance Win

No malloc optimization can eliminate the waste of re-initializing an object from scratch. The fastest caching will be caching of almost-ready-to-go objects that don't require allocation and initialization from scratch. No malloc can provide that while sticking with malloc semantics.

It's a high risk area with no benefit to programs which don't spend a lot of time in malloc, or which recycle entire objects (dispensing with the cost of fully re-initializing recycled memory, not only the cost of malloc).

It's also not true that glibc's malloc has no arenas (which someone may interpret that way); they are just not tied to threads. For something like twenty years, glibc's malloc has had thread support roughly as follows: a thread walks a list of arenas and tries to acquire one without blocking. Then it allocates from that arena. So it's not exactly like there is one big lock around malloc. But threads don't have affinity to go to the same arena.