Default musl allocator considered harmful to performance

Summary

TLDR: In a real world benchmark, the default musl allocator caused a 7x slowdown compared to other allocators. I recommend all Rust projects immediately add the following lines to their application’s main.rs: // Avoid musl's default allocator due to lackluster performance // https://nickb.dev/blog/default-musl-allocator-considered-harmful-to-performance #[cfg(target_env = "musl")] #[global_allocator] static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc; And Cargo.toml [target.'cfg(target_env = "musl")'.dependencies] mimalloc = "0.1.43" The root cause is the contention between multiple threads when allocating memory, so the problem worsens as more threads or allocations are created. I recommend swapping the allocator even if musl is not a compilation target today or if the program is single threaded. This is something you simply don’t want to forget. Reader’s choice on what allocator they want to sub in. The code snippets use mimalloc, but jemalloc is also good. Also reader’s choice if allocation substitution should only be restricted to musl environments (as shown) or if it should be done globally. I don’t mind conditionally compiling dependencies here as it serves as another form of documentation. Why musl? If I feel so strongly about avoiding the default musl allocator, why even use musl in the first place? Well, when an important customer is running a version of Red Hat Linux initially released before I started high school, you can bet that there will be glibc issues if you don’t have a build machine with the same version of Red Hat Linux. Corollary: hats off to Red Hat for supporting their distro releases for such a lengthy period of time. So this is a love-hate relationship with musl. I love cross compiling and creating static executables where I can scp anywhere and just have everything work. I will continue to use musl and respect the hard work behind the team. And while docker image size should never be a deciding factor, it can be tantalizing to leverage ...