Don't use musl if you care about performance

If your algorithm does a ton of small allocations to the point where the allocator is the bottleneck, you're already doing it wrong. The allocator necessarily comes with a lot of overhead because it needs to accommodate diverse use cases, avoid fragmentation, and ideally, implement a variety of security checks. If you're doing something alloc-intensive, you're probably allocating and freeing a lot of identical structures and you'd be better off grabbing some continuous memory and managing that yourself in a task-specific way.

But the reality is that almost no one actually cares about performance because compute is cheaper than expertise and labor, at least in the short haul. Everything is getting more bloated and slower and we just compensate by adding CPU cores, gigabytes and gigahertz.

People have such different perspectives. 26% slower does not sound "terrible" to me; it sounds like quite a reasonable price one might choose to pay for the convenience musl offers. If musl's allocator were 2.6x slower, I might call that "not so great"... but in order to qualify as "terrible" I think the difference would have to be an order of magnitude!

This is only one aspect of "performance". glibc's allocator may be faster, but it also uses more memory.

For a much more technical discussion, see https://github.com/sharkdp/fd/issues/710

I really find complaints about the minimum viable placeholder malloc in musl confusing. Does anyone seriously try to use malloc-ng for performance critical use cases?

Our entire linux distro is musl based BUT we swap out the default malloc with mimalloc for high performance because why would you not? Best of both worlds.

https://codeberg.org/stagex/stagex/src/branch/main/packages/...

Posted this the other day but the whole musl allocator thing seems to be well known [0]

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

I think the size of linked binaries and simplicity were always the main features?

I feel with Rust I try and avoid re-allocations in most cases anyway, so I'm not sure that musl's allocator being slow would significantly affect performance (though I haven't benchmarked it). I feel like part of the appeal of Rust is that you can do imperatively-style mutation-heavy code comparatively risk-free, so despite me normally being the "Functional Programming Nerd", I generally write Rust in a style that's a bit closer to C.

I use musl for my Rust stuff because I have noticed that for the stuff I write it appears to have a lower memory footprint; since a lot of what I do is IO-bound anyway, I care more about using less memory than raw performance.

Are there other options if I want to ship a 'FROM scratch' image with just a single Rust executable, and everything compiled in?

That to me is the main driver for MUSL.

I swear "bifrost" has to be the most overused name in computing, possibly only behind "yggdrasil." I'm not sure what's so magnetic about those names but I've seen at least 10 different things called that.

Also musl is not a complete runtime

Funny thing is that the major reason most people use musl is because glibc make it (artificially) hard to do completely static linking.

[dead]

[dead]

Most of musl's performance issues come from their allocator. Using it with a third party high performance allocator allows you to benefit from static linking with very little performance loss.