I especially like the part near the end of the post where it says, "It could be that different implementations excel in different scenarios" as if that wasn't completely obvious for anyone who has thought for more than a few minutes about a malloc implementation.
Article author here -- apologies for making you dumber. I would love to hear any data you have about when I should choose one malloc() implementation over another; the theory that malloc implementations have trade-offs is basic enough, but I've never come across a memory allocator that says "here are situations where you shouldn't use this allocator, and should use allocator Y instead."
And since the malloc() that ships with any given libc is going to be used by 100% of applications that do not explicitly override malloc (and I have never come across an application that does), understanding which is the best all-around allocator seems like quite the worthwhile exercise.
I also don't necessarily buy the jemalloc paper's assertion that allocators cannot be benchmarked in isolation. It's true that you can't measure the effects that locality will have on the rest of the application, but you surely can measure locality of allocations.
General purpose malloc/free cannot "rule" in all situations due to its limited interface hence any particular understanding of resource management constraints. It's obvious that no malloc/free package can possibly outperform an arena scheme when it makes sense.
