musl's allocator is a footgun: Bifrost benchmarks show 25% slower performance

Don't use musl if you care about performance

musl's allocator is a footgun: Bifrost benchmarks show 25% slower performance

Jonathan Ellis, creator of Bifrost, a Rust-based code analysis tool, benchmarks musl against glibc and finds musl's default allocator causes significant performance regressions, up to 25% slower overall. Even with mimalloc, musl remains 26% slower than glibc due to slow memory routines beyond the allocator. Ellis decides to drop musl as a prebuilt option for Bifrost, while keeping it for smaller projects where performance is less critical.

This is a really bad footgun to leave loaded for users and honestly, I think musl should ship without an allocator and make you choose one.
  1. matherial

    If your algorithm does a ton of small allocations to the point where the allocator is the bottleneck, you're already doing it wrong. The allocator necessarily comes with a lot of overhead because it needs to accommodate diverse use cases, avoid fragmentation, and ideally, implement a variety of security checks. If you're doing something alloc-intensive, you're probably allocating and freeing a lot of identical structures and you'd be better off grabbing some continuous memory and managing that yourself in a task-specific way.

    But the reality is that almost no one actually cares about performance because compute is cheaper than expertise and labor, at least in the short haul. Everything is getting more bloated and slower and we just compensate by adding CPU cores, gigabytes and gigahertz.

  2. marssaxman

    People have such different perspectives. 26% slower does not sound "terrible" to me; it sounds like quite a reasonable price one might choose to pay for the convenience musl offers. If musl's allocator were 2.6x slower, I might call that "not so great"... but in order to qualify as "terrible" I think the difference would have to be an order of magnitude!

  3. bloppe

    This is only one aspect of "performance". glibc's allocator may be faster, but it also uses more memory.

    For a much more technical discussion, see https://github.com/sharkdp/fd/issues/710

  4. mattrighetti

    Posted this the other day but the whole musl allocator thing seems to be well known [0]

    [0]: https://news.ycombinator.com/item?id=45143347

  5. grep_it

    I think the size of linked binaries and simplicity were always the main features?

More from this day

2026-08-28