I went from an Ubuntu to an Alpine desktop and it was like bolting on a turbo. You know that rush when the turbo spools up and then it just plants you in your seat and you rocket away? Like this wasn't just "I think it's faster", I was like laughing and shouting it was so much faster. It doesn't seem quite as fast now; I feel like I must have added on enough extra software and crap now that it's close to where it was before. But the feeling when bringing up the desktop for the first time was visceral.

I've tried alpine's gcc before and it was about 50% slower to compile a bunch of packages. That said, if you compile llvm with MinSize/-Os on glibc distro's it runs 50% slower too, so it's unclear if slowdown is due to musl libc or rather that they optimize for size instead of performance.

Compiling is CPU-bound and doesn't really bottleneck on anything that libc is involved with other than the allocator, so unless musl's allocator is comically slower than glib's, chances are it's just -Os.

This is pretty much -Os. Void Linux provides -O2 builds of GCC for both musl and glibc with a negligible performance difference. I have not benchmarked it lately, but it is clearly below 10%.

I believe musl’s allocator is known for being pretty poor.

musl-1.2.1.tar.gz (sig) - August 4, 2020

    This release features the new "mallocng" malloc implementation, replacing musl's original dlmalloc-like allocator that suffered from fundamental design problems.

https://inbox.vuxu.org/musl/20200518194204.GG21576@brightrai... Pretty good writeup from the author

https://musl.libc.org/releases.html Rest of the detail in the actual changelog is worth reviewing too

Sounds like my information is out of date!

Anecdotal but I work on a performance oriented application and there is no such measured performance penalty from musl. For that particular use-case, like all benchmark caveats. Older musl, perhaps. Musl in other domains that bottleneck on something less performant, perhaps. Ymmv, measure twice cut once. :)