Don't use musl if you care about performance

Most of the useful discussion landed on a narrower but stronger claim than the title. musl’s allocator is widely seen as the main culprit, especially for multithreaded programs, because it serializes allocation work too aggressively and gets worse as concurrency rises. Several commenters also said the article’s more interesting point is that the remaining loss does not disappear with a better allocator. musl’s memcpy, memset, and string routines leave performance on the table compared with glibc’s heavily tuned, microarchitecture-dispatched implementations. That makes the tradeoff less about one bad subsystem and more about musl choosing simplicity and small size over aggressive optimization across the libc surface. The practical defense of musl was consistent too. People use it because static linking with glibc is awkward, because a single self-contained binary is easy to ship, and because smaller binaries or lower memory use can matter more than throughput for IO-bound tools and container utilities. The pushback was not that musl is useless. It was that many teams treat it like a free operational win when it is really a conscious exchange: simpler deployment and smaller artifacts in return for lower peak performance, with the penalty especially sharp in threaded server workloads.