How to speed up the Rust compiler in September 2026

torutofu

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.

Citrusoff

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.

Surac

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?

adamch

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.

bryanlarsen

Really nice to see that the 5% speedup is despite making the borrow checker better, validating code that previously would have tripped it up. Sometimes we really can have our cake and eat it too.

maherbeg

I'm surprised the OpenAI Codex team doesn't donate like 10B tokens or something to the Rust team for performance

hnp9j9qtda

Biggest win for me was splitting one fat crate into three, parallelism got real.

ddalcino

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

slowin

I've moved from Rust to Go for most things because in the era of agents, being able to iterate quickly on a project is a huge advantage and Rust is way, way slower than Go for compilation. There are times when Rust is more appropriate, but for the vast majority of things Go is perfectly fine.

s08148692

I finally gave in to the rust hype and built a new project in it (or my agent fleet did). Almost instant regret. My poor machine with just 2TB HDD and 24 cores was almost immediately crippled by agents each working in their own sandbox, each one building and compiling Most projects my fleet works on are in other languages (TS, Go, Elixir) and can comfortably handle 10+ agents working in parallel, but not rust. I had to cap the fleet to 5 workers and build a dedicated resource monitor to step in and tidy up every time the disk almost filled up That and general progress on building is far slower, with far more time spent building and testing than any other language I use. Ended up rebuilding in Go, the perf gains weren't worth it

muthuh

Oh man just miseed it, October already.

knuckleheads

Funny to see this now. I’ve got a private branch I am in the process of shaping up this weekend to show the compiler team. For deep nested projects like rust analyzer, if you emit the meta data about function types earlier for downstream slots to use, before successful type checking, you can start other crates earlier and use all the slots you have instead of sitting around waiting for the full type checking of the bodies (which other crates largely don’t care about). Something like 40% wall time speed up, maybe 10% to 15% if you have the parallel frontend on.

randypewick

I recall a talk about makepad.dev, I think it was by Rik Arends, that explained how they achieved outstanding compilation times in rust for makepad. I can't find that talk again, but it was quite interesting: the rust compiler is fast, but often times it has to perform a lot of unnecessary checks because crates contain more stuff than needed. By stripping unnecessary work, the makepad team made building pretty fast.

dabinat

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

1vuio0pswjnm7

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

sharktheone

I think there are a few more. Especially cranelift, but I would not use it for production stuff and it is missing a lot of llvm intrinsics that will just trap if you are trying to use them. But for most it seems to be just fine for regular dev builds with a HUGE speedup.

jongjong

I don't understand why developers are interested in Rust. - Raw performance doesn't actually matter for the vast majority of use cases. Performance does not equate scalability. Moreover, differences usually disappear in practice once you've actually developed the software because time and storage complexity of operations usually dwarf constant resource costs. Furthermore, do you realize how much more computational resources AI uses compared to a classic piece of software? Trying to optimize tools in the age of AI is like putting lipstick on a pig. - It's more verbose than most other languages; waste of tokens, context window, time and AI reasoning capacity. The strain most devs feel when reading Rust, also impacts LLMs. It obfuscates essential logic and replaces it with ceremony. - The Rust training set is far smaller than other popular programming languages. It's also quite different from other programming languages so it probably doesn't benefit as much from cross-language patterns; in fact, could be problematic. - You have to wait for a compiler; more wasted time which the AI agent could have been using to write code. It's like TypeScript. Devs became obsessed with TypeScript. Everyone was sure that it would be better for AI. Not the case. LLMs essentially never make type errors in JavaScript (or TypeScript). Static typing is completely redundant. These are the most trivial kinds of errors to avoid. Seriously, try Claude with vanilla JavaScript on Node.js. TypeScript is worse with AI because people who used it tended to over-engineer, also a lot of TypeScript is ceremonial and performative complexity intended for a bureaucratic audience; those are the main patterns which AIs picked up from their training set. Seriously, try working with a TypeScript codebase and notice how Claude invents all these contrived abstractions, spread out over a huge number of files with unclear separation of concerns and full of lengthy, highly contrived comments. It's the same issue with all these over-engineered languages which were developed for people who were not good at coding and needed a whole bunch of extra safety features in order to produce functioning software. It's like training wheels on a bike; great to learn in the early stages but if you want to learn how the pros do it, you've got to look at the people who compete in the Olympics; and note that there's a reason none of them still have training wheels on their bikes!