Avoid musl if Performance is Your Priority

By Jonathan Ellis — August 27, 2026

For the majority of my professional life, I've operated within the realm of the JVM, with some experience in Python on the side. Consequently, when I ran into libc incompatibility issues while containerizing Bifrost, I took a suggestion from GPT to switch to musl. I didn't just stop there; I migrated several of my other Rust-based projects to musl as well.

The allure was simple: standard binaries self-contained binaries supported by a single, unified implementation.

The Performance Wake-Up Call

The honeymoon phase ended when my colleague, Ryan, pointed out that musl is notorious for having a suboptimal memory allocator. He directed me toward an analysis by Daniel Raneland.

Contrary to some common narratives, these performance hits aren't limited to high-concurrency environments. The data was gathered from 4-core EC2 VMs, and Bifrost's thread pools are scaled specifically to match that hardware.

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

If a user chooses a poor allocator because they prioritize a tiny code footprint, that's their choice. Instead, musl currently presents a "surprise" that users only discover after the fact.

Testing the "Magic Wand"

I attempted to mitigate the issue by swapping the default allocator for mimalloc (or jemalloc). However, this isn't a total fix. Even with mimalloc, musl remains significantly slower than glibc.

Mathematically, the performance gap can be viewed as: $\text{Performance}_{\text{musl+mimalloc}} \approx 0.74 \times \text{Performance}_{\text{glibc}}$

This represents a 26% performance penalty.

Comparative Analysis of Task Types

I analyzed two specific tasks to understand where the regressions were coming from:

While scan_usages saw some gains from mimalloc, structural_clone_smells (s_c_s) barely allocates memory at all. Despite this, s_c_s suffered a greater proportional slowdown on musl than scan_usages did.

The Verdict: Simplicity Isn't Free

The investigation revealed that the allocator isn't the sole culprit. Several common memory routines within musl are simply slow.

Decision Logic

To implement this, I'm changing my build configurations:

# For small projects like 'Hel'
# Keep musl for simplicity, but add mimalloc
cargo build --target x86_64-unknown-linux-musl 

Final Action Plan

• Analyze musl vs glibc benchmarks.
• Test mimalloc integration.
• Remove musl as a prebuilt option for Bifrost.
• Maintain musl + mimalloc for low-sensitivity projects (e.g., Hel).