4 ms·
(Well, rebuilding them with a different allocator that benchmarks well on their specific workflow.)
by kstrauser 2y ago
(Well, rebuilding them with a different allocator that benchmarks well on their specific workflow.)
- dan-robertson 2y agoIs it even known what workloads the glibc malloc is good for?
- searealist 2y agoUsing all your memory on multi-threaded workflows.
- rurban 2y agoIt's using the least additional memory, compared to all others. Whilst being the slowest by far of all modern allocators.
- loeg 2y agoEverything outperforms glibc malloc. It's essentially malpractice that distros continue to use it instead of mimalloc or jemalloc.
- throw16180339 2y agoIt'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.
- loeg 2y agoNo 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).