| ▲ | How to speed up the Rust compiler in September 2026(nnethercote.github.io) | |||||||
| 18 points by trickypr an hour ago | 6 comments | ||||||||
| ▲ | adamch 3 minutes ago | parent | next [-] | |||||||
I'm glad to see the donations from big companies to open source maintainers are making measurable difference to the Rust experience. Telling these companies that their employees spend 5% less time waiting for compilation might motivate future investment in people like Nick and the others mentioned. | ||||||||
| ▲ | Surac 8 minutes ago | parent | prev | next [-] | |||||||
Why is the compiler slow in the first place? I have no rust knowledge, how slow us slow, lets say in comparison to a c compiler? What is the performance killer? | ||||||||
| ||||||||
| ▲ | Citrusoff 23 minutes ago | parent | prev | next [-] | |||||||
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. | ||||||||
| ||||||||
| ▲ | torutofu 29 minutes ago | parent | prev [-] | |||||||
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. | ||||||||