-
Notifications
You must be signed in to change notification settings - Fork 84
Investigate musl performance issues #8
Comments
wow |
Interesting. I’m not much help here but subscribing because I was just about to migrate our Rust services to musl... |
So, replacing the system allocator with jemalloc basically returns musl performance to glibc, but this doesn't seem right as a "fix" as it would be sweeping a problem under the rug. The root of the problem would seem to be heap allocations occuring inside many different threads, which musl seems to not handle well at all. Reducing/removing/pre-allocating memory will probably improve performance for all targets, not just musl, so will investigate that later. |
Just curious, is there an open issue about this over at the Musl tracker? Pretty confident they would love to know about this 🙃 This is an inexcusable performance hit. EDIT: TIL Musl doesn't have a dedicated tracker, it seems. They have a mailing list described on their site. Might be worth it for a maintainer to direct them toward this issue. |
is this issue still a thing? running |
Good question, I haven't checked in a long time, thanks for the heads up! |
There is a huge performance gap between
x86_64-unknown-linux-musl
andx86_64-unknown-linux-gnu
that needs to be investigated, as we use musl for our pre-built linux binaries.Doing the same CLI operation shows how severe this performance gap is:
The text was updated successfully, but these errors were encountered: