On: Default musl allocator considered harmful to performance

[dijit]

I’d much rather go with distroless, if its a choice.

But I think you can tweak musl to perform well, and musl is closer to the spec than glibc so I would rather use it; even if its slower in the default case for multithreaded programmes.

[masklinn → dijit]

> But I think you can tweak musl to perform well

You can not, its allocator does thread safety via a big lock and that’s that.

> musl is closer to the spec than glibc

Is it?

> even if its slower in the default case for multithreaded programmes.

That’s far from the only situation where it’s slower though.

[dijit → masklinn]

Yeah, the musl people tend to closely follow the spec, this doesn’t always win them friends: https://news.ycombinator.com/item?id=22682510

Swapping out jemalloc for the system allocator will net you huge performance wins if you link against musl, but you’ll still have issues with multithreading performance due to the slower implementations of necessary helpers.

[adgjlsfhk1 → dijit]

Sometimes the spec sucks. A lot of the UNIX specs were written before anyone knew how to program multi-threaded systems, and thus are impossible to implement correctly (setenv is probably the most famous example)