How to speed up the Rust compiler in September 2026

dabinat 5 hours ago|

The parallel frontend is inching closer to stability too, with an open PR to enable it by default on nightly.

But the real speedup will happen when TPDE is enabled: https://goals.rust-lang.org/2026/tpde.html

torutofu 9 hours ago||

Incremental seems to keep winning the easy wins, so the interesting part is whether the remaining compile-time still lives in the same places as last year.

1vuio0pswjnm7 4 hours ago||

How does the Rust compiler's speed compare to the speed of the C compiler GCC

Is it slower

muthuh 6 hours ago||

Oh man just miseed it, October already.

mattz56 7 hours ago||

[dead]

ddalcino 7 hours ago||

Gonna have to name my next project Penelope Hammertime, or at least Pineapple Häagen-Dazs.

Citrusoff 9 hours ago|

The EverInitializedPlaces example really stands out. Going from ~1.5M to ~90K apply_effects_in_block calls by changing the CFG traversal is a reminder that the biggest compiler optimizations often come from changing the algorithm, not optimizing the hot loop itself.

It also seems like the new Polonius/trait-solver work is pushing compiler performance toward a more interesting problem: doing expensive analysis only when it is actually needed.

4.57% mean wall-time reduction across 629 benchmarks in two months is pretty remarkable. Great progress.

embedding-shape 9 hours ago|

> reminder that the biggest compiler optimizations often come from changing the algorithm, not optimizing the hot loop itself.

Isn't this true for most optimizations, not just in compilers? My usual goto process for optimizing is "Find stuff we're doing that we don't have to do, re-evaluate what data structures we use and then re-evaluate what algorithms we use" basically, with minor changes depending on the results. Served me well so far, and haven't (intentionally) written any compilers.

dev_hugepages 6 hours ago||

This isn't a human you are asking your question to.