> Given that we now fully utilize 128 threads or 64 cores for pretty much the entire compile time, we can do a back of the envelope calculation for how long it should take: 25 min / 128 = 12 sec (or maybe 24 sec since hyper-threads aren't real cores). Yet it takes 170s to compile everything.

Amdahl’s Law would like to have a word.

Eminently pragmatic solution — I like it. In Rust, a crate is a compilation unit, and the compiler has limited parallelism opportunities, especially since rustc offloads much of the work to LLVM, which is largely single-threaded.

It’s not surprising they didn’t see a linear speedup from splitting into so many crates. The compiler now produces a large number of intermediate object files that must be read back and linked into the final binary. On top of that, rustc caches a significant amount of semantic information — lifetimes, trait resolutions, type inference — much of which now has to be recomputed for each crate, including dependencies. That introduces a lot of redundant work.

I also would expect this to hurt runtime performance as it likely reduces inlining opportunities (unless LTO is really good now?)

The main issue here is:

- in rust one semantic compilation unit is one crate

- in C one semantic compilation unit is one file

There are quite a bunch of benefits in the rust approach, but also drawbacks, like huge projects have to be split into multiple workspaces to maximize parallel building.

Oversimplified the codegen-units setting tells the compiler into how many parts the compiler is allowed to split the a single semantic code gen unit.

Now it still seems strange (as in it looks like a performance bug) that most times rust was stuck in just one threat (instead of e.g. 8).

> We're using rustc v1.83, and despite having a 64-core machine with 128 threads, Rust barely puts any of them to work.

> That’s right — 1,106 crates! Sounds excessive? Maybe. But in the end this is what makes rustc much more effective.

> What used to take 30–45 minutes now compiles in under 3 minutes.

I wonder if this kind of trick can be implemented in rustc itself in a more automated fashion to benefit more projects.

For any Rust compiler experts interested in taking a look, I've put together a short repro here: https://github.com/feldera/feldera/issues/3882

It will give you a workspace with a bunch of crates that seems to exercise some of the same bottlenecks the blog post described.