[sim7c00]

maybe its not 'slow' but more 'generalized for a wide range of use-cases'? - because is it really slow for what it does, or simply slower compared to a specialized implementation? (this is calling a regular person car slow compared to an F1 car... sure the thing is fast but good luck takin ur kids on holiday or doing weekly shopping runs?)

[saagarjha]

glibc is faster in basically every usecase, though.

[masklinn]

“Generalised to a wide range of use cases” is a really strange way to say “unsuitable to most multi-threaded programs”.

In 2025 an allocator not cratering multi-threaded programs is the opposite of specialisation.

[flohofwoe]

It only matters when your threads allocate with such a high frequency that they run into contention.

A too high access frequency to a shared resource is not a "general case", but simply poorly designed multithreaded code (but besides, a high allocation frequency through the system allocator is also poor design for any single-threaded code, application code simply should not assume any specific performance behaviour from the system allocator).

[Joker_vD]

Well, what is "such a high frequency"? Different allocators have different breaking points, and the musl's one is apparently very low.

> application code simply should not assume any specific performance behaviour from the system allocator

Technically, yes. Practically, no; that's why e.g. C++ standard mandates time complexity of its containers. If you can't assume any specific performance from your system, that means you have to prepare for every system-provided functionality to be exponentially slow and obviously you can't do that.

Take, for instance, the JSON parser in GTA V [0]: apparently, sscanf(buffer, "%d", &n) calls strlen(buffer) internally, so using it to parse numbers in a hot loop on 2 MiB-long JSON craters your performance. On one hand, sure, one can argue that glibc/musl developers are within their right to implement sscanf however inefficiently they want, and the application developers should not expect any performance targets from it, and therefore, probably should not use it. On the other hand, what is even the point of the standard library if you're not supposed to use it for anything practical? Or, for that matter, why waste your time writing an implementation that no-one should use for anything practical anyhow, due to its abysmal performance?

[0] https://news.ycombinator.com/item?id=26296339