Hacker News Reader

(Well, rebuilding them with a different allocator that benchmarks well on their specific workflow.)

Everything outperforms glibc malloc. It's essentially malpractice that distros continue to use it instead of mimalloc or jemalloc.

It's been awhile since I looked into this, but it's not necessarily an easy change. glibc malloc has debugging APIs; a distro can't easily replace it without either emulating the API or patching programs that use it.

No need to even patch it out. It's relatively easy to change the default, rebuild the world (distros have a flow for this), and restore glibc for the tiny, tiny handful of individual programs that actually rely on glibc debugging APIs.

From a end developer perspective: I have no particular familiarity with mimalloc, but I know jemalloc has pretty extensive debugging functionality (not API compatible with glibc malloc of course).

Is it even known what workloads the glibc malloc is good for?

Using all your memory on multi-threaded workflows.

It's using the least additional memory, compared to all others. Whilst being the slowest by far of all modern allocators.

Reply on news.ycombinator.com