musl with mimalloc is still 26% slower than glibc on a 4-core box

Brokk benchmarked its Rust service Bifrost on musl and on glibc and published the delta: musl with mimalloc preloaded is still 26% slower than glibc. The measurements came from 4-core EC2 VMs, not a 64-core stress rig. The team's response was to remove musl as a prebuilt option for Bifrost entirely.

The path into the problem is a familiar one for anyone shipping containers. The author hit an incompatible libc with containerized Bifrost, GPT suggested musl as the fix, and the appeal of a self-contained binary with a single implementation behind it was enough to move other Rust projects to musl as well. A colleague, Ryan, later pointed out that musl is known to have a suboptimal allocator and linked Daniel Raneland's article on the subject. That prompted the actual measurement.

A common defense of musl is that its allocator only falls apart under heavy thread contention, so single-threaded or lightly-threaded services are safe. Brokk's numbers contradict that directly. The post states the regressions are not confined to high concurrency scenarios, and that the numbers come from 4-core EC2 VMs with Bifrost sizing its thread pools accordingly.

That is the sizing most agent sidecars, indexers and retrieval workers actually get in production, where CPU limits are set in single-digit cores and thread pools are derived from those limits. If you assumed the musl penalty was a large-machine problem, the measured result says otherwise for at least one real Rust workload at four cores.

The post breaks the residual gap down across the two task types with the worst regressions, and the two behave differently. That difference is the useful part of the writeup, because it tells you whether an allocator preload is even the right lever for your workload.

The conclusion the author draws from that pattern is that the allocator is not the only suboptimal code in musl, and that several common memory routines are particularly slow. For an allocation-light hot loop dominated by copies and comparisons, an LD_PRELOAD of mimalloc buys you nothing measurable. That is a concrete diagnostic: if profiling shows your hot path spends its time in memory routines rather than in malloc, the allocator swap is not going to recover the gap and you need a different libc.

The practical framing in the post is a footgun argument rather than a purity argument. The author's position is that musl should ship without an allocator and make you choose one, so that picking a bad allocator is an explicit decision instead of an undocumented default you discover through a production regression.

Brokk split its own projects on the size of the number. Smaller projects where 25% slower does not matter, such as Hel, stay musl-only for simplicity, with mimalloc added. The much-more-performance-sensitive Bifrost loses musl as a prebuilt option. That is a reasonable template for anyone maintaining a mix of internal tools and latency-sensitive services: keep the static, dependency-free build where the throughput budget is loose, and move to glibc where it is not.

It is worth being precise about what triggered the original migration, because the same trigger is everywhere in container work. The move to musl was a fix for an incompatible libc in a container, not a performance decision. Compatibility fixes that quietly change your allocator and memory routines deserve a benchmark before they become the default build target across a fleet.

The writeup reports one aggregate figure, 26% for musl with mimalloc, plus a directional breakdown of two task types. It does not publish per-routine microbenchmarks for the slow memory routines it names, and it does not report a separate jemalloc number; jemalloc appears only bracketed alongside mimalloc in the parity claim. There is no measurement of static-pie versus dynamically linked glibc builds, no container image size comparison, and no absolute latency figures to anchor the percentages.

So the transferable claim is narrower than "musl is slow": for one Rust workload on 4-core EC2, glibc beat musl by a margin that mimalloc reduced but did not close, and the residual came from something other than allocation. If you are running Rust agent tooling or inference-adjacent services on Alpine-style images, the cheap next step is to build the same binary against glibc, run your own two worst tasks on the CPU limit you actually deploy with, and see whether your gap looks like scan_usages or like structural_clone_smells. Only the first of those is fixable with a preload.