My own perf comparison: when I switched from Fil-C running on my system’s libc (recent glibc) for yololand to my own build of musl, I got a 1-2% perf regression. My best guess is that it’s because glibc’s memcpy/memmove/memset are better. Couldn’t have been the allocator since Fil-C’s runtime has its own allocator.
That table is unfortunately quite old. I can't personally say what have changed, but it is hard to put much confidence in the relevance of the information.
Please note that the linked comparison table has been unmaintained for a while. This is even explicitly stated on the legacy musl libc website[0][0] (<i>i.e.</i>, “The (mostly unmaintained) libc comparison is still available on etalabs.net.”).<p>[0]: <a href="https://www.musl-libc.org" rel="nofollow">https://www.musl-libc.org</a>
The static compilation of musl libc is a huge help for alpine linux and many system programming languages. My programming language <a href="https://github.com/nature-lang/nature">https://github.com/nature-lang/nature</a> is also built on musl libc.
It really ought to lead with the license of each library. I was considering dietlibc until I got to the bottom - GPLv2. I am a GPL apologist and even I can appreciate that this is a nonstarter; even GNU's libc is only LGPL!
It’s amazing how much code gets pulled in for printf. Using musl, printf apparently adds 13kb of code to your binary. Given format strings are almost always static, it’s so weird to me that they still get parsed at runtime in all cases. Modern compilers even parse printf format strings anyway to check your types match.<p>This sort of thing makes me really appreciate zig’s comptime. Even rust uses a macro for println!().