I did some performance testing with my Rust application (on x86-64 Linux) and I found that target x86_64-unknown-linux-musl reduces the throughput of my application by a significant 25%, compared to building the exactly same code with x86_64-unknown-linux-gnu:

$ cargo run --release --target=x86_64-unknown-linux-gnu -- -T
Median execution time: 18.1 seconds (107.90 MiB/s)

$ cargo run --release --target=x86_64-unknown-linux-musl -- -T
Median execution time: 23.9 seconds (81.69 MiB/s)

(This was tested with Rust 1.91.1 on Ubuntu 25.10)

It is important to note that my application is definitely CPU bound. It does not perform much I/O. Actually, in the self-test mode, which I use for performance testing, it does not really perform any I/O at all. Also, I don't do any dynamic memory (de)allocation. All the buffers are allocated once, at the start, and will be de-allocated only at the end.

So how can just linking a different C library make such a big difference in performance? All the actual computations, which form the bottleneck for throughput, are done in pure Rust code!

I found this:

However, using MiMalloc did not make any difference with my application.

(Not much surprising, since, as said before, my application does not do a lot of allocations)

Any more ideas, what might be the culprit here?

Of course, I could simply go with x86_64-unknown-linux-gnu, but I much prefer using x86_64-unknown-linux-musl for the release binaries

Best regards.

2 posts - 2 participants

Read full topic