My last post on the Rust compiler’s performance was two months ago and a lot has happened since then.
\nThe measurements for the period 2026-07-29 to 2026-09-28 can be seen here.
\nThe mean wall-time reduction was 4.57%, which is a remarkable improvement in just two months. Of the 629 benchmark measurements, 555 of them improved and only 74 regressed. A number of benchmarks saw double-digit percentage reductions. The technical term for this result is “a sea of green”.
\nIn my last post I mentioned how Noah Lev got some enormous speed wins on rustdoc. He recently wrote a post explaining in some detail exactly how he did this. It’s an interesting and satisfying read.
\n#159642: In this PR Jakub Beránek enabled PGO for Clippy, giving wall-time improvements across most Clippy benchmarks, in the best case by 18%!
\n#158734: In this PR Nikita Popov upgraded the LLVM version used by the compiler to LLVM 23. As often happens when we upgrade LLVM, we saw some nice speedups. The mean wall-time reduction across all benchmarks was 1.2%, which might not sound like much but is really impressive for a single PR. Great work from the LLVM folks!
\nThe new borrow checker, Polonius Alpha (no relation to Napoleon Dynamite), was enabled on Nightly. It is more precise than the existing borrow checker and accepts some valid programs that the old borrow checker would reject. It does do more work than the old borrow checker, enough to make a measurable difference to compile time in a minority of cases, including the popular serde crate. Fortunately, Jack Huey has been on the case.
#161938: In this PR Jack made some liveness computations lazy, which reduced instruction counts for serde by 3-5%, and for some other benchmarks by less than 1%.
#163027: In this PR Jack adjusted a data structure and tweaked some inlining, for mostly sub-1% instruction count reductions across numerous benchmarks.
\nThere is more work to be done to reduce the remaining Polonius Alpha regressions, but it’s worth noting that the “sea of green” shows these regressions were swamped by the many other recent improvements.
\nThe new trait solver, Penelope Hammertime, [Ed. note: is that right?] was also enabled on Nightly.
\nAs I said, a lot has been happening.
\nLike the new borrow checker, the new trait solver is slower in a minority of cases. Jana Dönszelmann wrote a detailed post about the efforts to improve the performance of this new solver.
\nJana’s post is detailed enough that I won’t say much more about the large amount of ongoing work on the new solver, but I will mention in passing the PRs I made: #160479, #160605, #160801, #160892, #161077, and #161211. Some of these reduced compile times greatly for certain outlier crates: 50% here, 25% there, 15% there, and even more on one stress test. And I am not the only one who has made progress here… go read Jana’s post.
\nNew contributor xmakro continued their run of good improvements.
\n#157281: In this PR xmakro optimized impl handling when building the specialization graph. This gave a mean cycle count reduction of 1.58% across all benchmarks, which is huge for a single PR.
\n#158059: In this PR xmakro optimized one aspect of the loading of incremental compilation data, reducing instruction counts across multiple benchmarks, in the best case by 6%.
\n#160473: In this PR xmakro avoided some allocations in a hot obligations processing path, reducing instruction counts across numerous benchmarks, in the best case by 2%.
\n#160268: In this PR xmakro avoided a lot of allocations by changing the old/new trait solver selection code to use static dispatch instead of dynamic dispatch. This gave mostly sub-1% instruction count reductions across a number of benchmarks. This hot allocation path had been showing up in profiles for a while and I had earlier tried exactly the same idea in #155714. But I got regressions on a couple of benchmarks, possibly due to slightly different choices of where to place some #[inline] attributes. It was good to see this obvious inefficiency fixed.
#160193: In this PR I changed the CFG traversal algorithm used by the dataflow analyses in the compiler. These analyses iterate to a fixpoint and the traversal algorithm can affect how quickly the fixpoint is reached. For most code the new algorithm makes no difference, but the cranelift-codegen crate has one enormous function with over 18,000 basic blocks. The old algorithm required 1.5 million calls to apply_effects_in_block to reach a fixpoint for the EverInitializedPlaces analysis used by the borrow checker; the new algorithm requires 90,000. This gave an enormous ~30% wall-time reduction for a check build of this crate.
#160033: In this PR I made EverInitializedPlaces more efficient again, this time by not tracking unnecessary data for projections. This reduced instruction counts on the match-stress benchmark by 17%, and on a few other benchmarks by less than 1%.
They’ve gotten very good at certain kinds of analysis. I’m still writing all my own code and text, because (a) that’s paramount, and (b) the project policy requires it, but I had useful LLM analysis assistance on several of the PRs mentioned in this post.
\nAnyway, enough about that.
\n#160535: In this PR Chris Denton increased the default stack size used by the compiler, which allowed the removal of ensure_sufficient_stack, a manual stack extension mechanism sprinkled about in places prone to high levels of recursion. There was a lot of discussion about this one because it can be difficult to decide how to best deal with stack exhaustion. But the performance effects are clear, with reduced instruction counts across many benchmarks, in the best case by almost 3%.
#160506: The project uses a lot of “rollup” PRs, where multiple PRs are merged together. This is because we don’t have sufficient CI capacity to merge every PR individually. Normally PRs that affect performance are merged by themselves so we can measure their effects clearly. For the first time ever, at one point we had so many performance improvement PRs waiting in the merge queue that Jonathan Brouwer created a rollup containing 10 performance-improving PRs to keep things moving! This is a good problem to have. And later on we had #162859 which contained four performance-improving PRs. (You needn’t worry about unexpected effects slipping in because we have the ability to run the perf benchmark suite on the individual PRs after merging, to make sure each PR had the expected performance effect.)
\n#162747: In this PR I made some minor improvements to the code that lowers AST to HIR. It was a cleanup that wasn’t expected to affect performance but it reduced instruction counts across numerous benchmarks, in the best case by 1.5%. Sometimes you get lucky.
\nTomorrow I will start working at Hexcat on the compiler performance optimizations project goal. It’s exciting! Many thanks to Mara Bos, Predrag Gruevski, and all the other people who helped make this happen.
\nThe new solver’s name is not Penelope Hammer
\ntime; that was a joke.
Its real name is Pineapple Häagen-Dazs.
\n", "date_modified": "2026-09-30T02:08:22+00:00", "date_published": "2026-09-30T02:08:22+00:00", "external_url": "https://nnethercote.github.io/2026/09/30/how-to-speed-up-the-rust-compiler-in-september-2026.html", "id": "urn:aggr:item:d76821c138046940cdb305868fdb1b0b5279d504", "summary": "Comments", "tags": [ "news", "compilers", "rust", "vibecoding" ], "title": "How to speed up the Rust compiler in September 2026", "url": "https://aggr.aymericbeaumet.com/items/lobste-rs/2026-09-30-how-to-speed-up-the-rust-compiler-in-september-2026/" } ], "language": "en", "title": "nnethercote.github.io", "version": "https://jsonfeed.org/version/1.1" }