{"article":{"slug":"how-to-speed-up-the-rust-compiler-in-september-2026","title":"How to speed up the Rust compiler in September 2026","subtitle":null,"summary":"How to speed up the Rust compiler in September 2026 My last post](https://nnethercote.github.io/2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html) on the Rust compiler’s performance was two months ago and a lot has happened since then. Overall progress The measurements for the period 2026-07-29 to 2026-09-28 can be seen here](https://perf.rust-lang.org/compare.html?start=1a833e16546c2eb012758ddd499964fd8afee29e&stat=wall-time&tab=compile&end=c1070d69382b8d2f2eb65119c738a77d9e324c9e&","content_type":"blog_post","language":"en","canonical_url":"https://nnethercote.github.io/2026/09/30/how-to-speed-up-the-rust-compiler-in-september-2026.html","author":{"name":"Nicholas Nethercote","url":"https://nnethercote.github.io/","person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Nicholas Nethercote","url":"https://nnethercote.github.io/","listing_slug":null,"listing":null},"topics":[{"name":"Rust","slug":"rust","url":"https://listedarticles.com/topics/rust"},{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"Performance","slug":"performance","url":"https://listedarticles.com/topics/performance"},{"name":"Compilers","slug":"compilers","url":"https://listedarticles.com/topics/compilers"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1212,"reading_minutes":5,"published_at":"2026-09-30T12:00:00.000Z","added_at":"2026-10-01T15:13:18.216Z","updated_at":"2026-10-01T15:13:18.216Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":false},"profile_url":"https://listedarticles.com/articles/how-to-speed-up-the-rust-compiler-in-september-2026","markdown_url":"https://listedarticles.com/articles/how-to-speed-up-the-rust-compiler-in-september-2026.md","example":false,"citation":"Nicholas Nethercote, Nicholas Nethercote. \"How to speed up the Rust compiler in September 2026.\" 30 Sept 2026. https://nnethercote.github.io/2026/09/30/how-to-speed-up-the-rust-compiler-in-september-2026.html (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://nnethercote.github.io/2026/09/30/how-to-speed-up-the-rust-compiler-in-september-2026.html"},"body_markdown":"# How to speed up the Rust compiler in September 2026\n\nMy [last\npost](https://nnethercote.github.io/2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html)\non the Rust compiler’s performance was two months ago and a lot has happened\nsince then.\n\n## Overall progress\n\nThe measurements for the period 2026-07-29 to 2026-09-28 can be seen\n[here](https://perf.rust-lang.org/compare.html?start=1a833e16546c2eb012758ddd499964fd8afee29e&stat=wall-time&tab=compile&end=c1070d69382b8d2f2eb65119c738a77d9e324c9e&nonRelevant=true).\n\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”.\n\n## rustdoc\n\nIn my last post I mentioned how [Noah Lev](https://github.com/camelid) got some\nenormous speed wins on rustdoc. He recently wrote [a\npost](https://noahlev.org/blog/2026/08/27/making-rustdoc-faster) explaining in\nsome detail exactly how he did this. It’s an interesting and satisfying read.\n\n## Clippy\n\n[#159642](https://github.com/rust-lang/rust/pull/159642): In this PR\n[Jakub Beránek](https://github.com/Kobzol) enabled PGO for Clippy, giving\nwall-time improvements across most Clippy benchmarks, in the best case by 18%!\n\n## LLVM update\n\n[#158734](https://github.com/rust-lang/rust/pull/158734): In this PR [Nikita\nPopov](https://github.com/nikic) upgraded the LLVM version used by the compiler\nto LLVM 23. As often happens when we upgrade LLVM, we saw some nice speedups.\nThe mean wall-time reduction across all benchmarks was 1.2%, which might not\nsound like much but is really impressive for a single PR. Great work from the\nLLVM folks!\n\n## The new borrow checker\n\nThe new borrow checker, [Polonius](https://en.wikipedia.org/wiki/Polonius)\n[Alpha](https://en.wikipedia.org/wiki/Alpha) (no relation to\n[Napoleon]()\n[Dynamite](https://www.youtube.com/watch?v=gdZLi9oWNZg)), was\n[enabled on\nNightly](https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-nightly/).\nIt is more precise than the existing borrow checker and accepts some valid\nprograms that the old borrow checker would reject. It does do more work than the\nold borrow checker, enough to make a measurable difference to compile time in a\nminority of cases, including the popular `serde` crate. Fortunately, [Jack\nHuey](https://github.com/jackh726) has been on the case.\n\n[#161938](https://github.com/rust-lang/rust/pull/161938): In this PR Jack made\nsome liveness computations lazy, which reduced instruction counts for `serde`\nby 3-5%, and for some other benchmarks by less than 1%.\n\n[#163027](https://github.com/rust-lang/rust/pull/163027): In this PR Jack\nadjusted a data structure and tweaked some inlining, for mostly sub-1%\ninstruction count reductions across numerous benchmarks.\n\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.\n\n## The new trait solver\n\nThe new trait solver,\n[Penelope](https://en.wikipedia.org/wiki/Anne_Hathaway)\n[Hammertime](https://www.youtube.com/watch?v=q8WSdypJ4WA),\n*[Ed. note: is that right?]* was also [enabled on\nNightly](https://blog.rust-lang.org/2026/08/21/enabling-next-solver-on-nightly/).\n\nAs I said, a lot has been happening.\n\nLike the new borrow checker, the new trait solver is slower in a minority of\ncases. [Jana Dönszelmann](https://github.com/jdonszelmann) wrote a [detailed\npost](https://donsz.nl/blog/new-solver-performance) about the efforts to\nimprove the performance of this new solver.\n\nJana’s post is detailed enough that I won’t say much more about the large\namount of ongoing work on the new solver, but I will mention in passing the PRs\nI made:\n[#160479](https://github.com/rust-lang/rust/pull/160479),\n[#160605](https://github.com/rust-lang/rust/pull/160605),\n[#160801](https://github.com/rust-lang/rust/pull/160801),\n[#160892](https://github.com/rust-lang/rust/pull/160892),\n[#161077](https://github.com/rust-lang/rust/pull/161077),\nand [#161211](https://github.com/rust-lang/rust/pull/161211).\nSome of these reduced compile times greatly for certain outlier crates: 50%\nhere, 25% there, 15% there, and [even\nmore](https://github.com/rust-lang/rust/issues/159933#issuecomment-5333109889)\non one stress test. And I am not the only one who has made progress here… go\nread Jana’s post.\n\n## xmakro\n\nNew contributor [xmakro](https://github.com/xmakro) continued their run of good\nimprovements.\n\n[#157281](https://github.com/rust-lang/rust/pull/157281): In this PR xmakro\noptimized impl handling when building the specialization graph. This gave a\nmean cycle count reduction of 1.58% across all benchmarks, which is huge for a\nsingle PR.\n\n[#158059](https://github.com/rust-lang/rust/pull/158059): In this PR xmakro\noptimized one aspect of the loading of incremental compilation data, reducing\ninstruction counts across multiple benchmarks, in the best case by 6%.\n\n[#160473](https://github.com/rust-lang/rust/pull/160473): In this PR xmakro\navoided some allocations in a hot obligations processing path, reducing\ninstruction counts across numerous benchmarks, in the best case by 2%.\n\n[#160268](https://github.com/rust-lang/rust/pull/160268): In this PR xmakro\navoided a lot of allocations by changing the old/new trait solver selection\ncode to use static dispatch instead of dynamic dispatch. This gave mostly\nsub-1% instruction count reductions across a number of benchmarks. This hot\nallocation path had been showing up in profiles for a while and I had earlier\ntried exactly the same idea in\n[#155714](https://github.com/rust-lang/rust/pull/155714). But I got regressions\non a couple of benchmarks, possibly due to slightly different choices of where\nto place some `#[inline]` attributes. It was good to see this obvious\ninefficiency fixed.\n\n## Dataflow analysis\n\n[#160193](https://github.com/rust-lang/rust/pull/160193): In this PR I changed\nthe CFG traversal algorithm used by the dataflow analyses in the compiler.\nThese analyses iterate to a fixpoint and the traversal algorithm can affect how\nquickly the fixpoint is reached. For most code the new algorithm makes no\ndifference, but the `cranelift-codegen` crate has one enormous function with\nover 18,000 basic blocks. The old algorithm required 1.5 million calls to\n`apply_effects_in_block` to reach a fixpoint for the `EverInitializedPlaces`\nanalysis used by the borrow checker; the new algorithm requires 90,000. This\ngave an enormous ~30% wall-time reduction for a `check` build of this crate.\n\n[#160033](https://github.com/rust-lang/rust/pull/160033): In this PR I made\n`EverInitializedPlaces` more efficient again, this time by not tracking\nunnecessary data for projections. This reduced instruction counts on the\n`match-stress` benchmark by 17%, and on a few other benchmarks by less than 1%.\n\n## LLMs\n\nThey’ve gotten very good at certain kinds of analysis. I’m still writing all my\nown code and text, because (a) that’s paramount, and (b) the [project\npolicy](https://forge.rust-lang.org/policies/llm-usage.html) requires it, but I\nhad useful LLM analysis assistance on several of the PRs mentioned in this post.\n\nAnyway, enough about that.\n\n## Miscellaneous\n\n[#160535](https://github.com/rust-lang/rust/pull/160535): In this PR [Chris\nDenton](https://github.com/ChrisDenton) increased the default stack size used\nby the compiler, which allowed the removal of `ensure_sufficient_stack`, a\nmanual stack extension mechanism sprinkled about in places prone to high levels\nof recursion. There was a lot of discussion about this one because it can be\ndifficult to decide how to best deal with stack exhaustion. But the performance\neffects are clear, with reduced instruction counts across many benchmarks, in\nthe best case by almost 3%.\n\n[#160506](https://github.com/rust-lang/rust/pull/160506): The project uses a\nlot of “rollup” PRs, where multiple PRs are merged together. This is because we\ndon’t have sufficient CI capacity to merge every PR individually. Normally PRs\nthat affect performance are merged by themselves so we can measure their\neffects clearly. For the first time ever, at one point we had so many\nperformance improvement PRs waiting in the merge queue that [Jonathan\nBrouwer](https://github.com/JonathanBrouwer) created a rollup containing 10\nperformance-improving PRs to keep things moving! This is a good problem to\nhave. And later on we had\n[#162859](https://github.com/rust-lang/rust/pull/162859) which contained four\nperformance-improving PRs. (You needn’t worry about unexpected effects slipping\nin because we have the ability to run the perf benchmark suite on the\nindividual PRs after merging, to make sure each PR had the expected performance\neffect.)\n\n[#162747](https://github.com/rust-lang/rust/pull/162747): In this PR I made\nsome minor improvements to the code that lowers AST to HIR. It was a cleanup\nthat wasn’t expected to affect performance but it reduced instruction counts\nacross numerous benchmarks, in the best case by 1.5%. Sometimes you get lucky.\n\n## Job status\n\nTomorrow I will start working at [Hexcat](https://hexcat.nl/) on the [compiler\nperformance\noptimizations](https://goals.rust-lang.org/2026/compiler-performance-optimization.html)\nproject goal. It’s exciting! Many thanks to Mara Bos, Predrag Gruevski, and all\nthe other people who helped make this happen.\n\n### *Editor’s postscript*\n\nThe new solver’s name is not\n[Penelope](https://en.wikipedia.org/wiki/Penelope,_Texas)\n[Hammer](https://www.youtube.com/watch?v=OJWJE0x7T4Q)[time](https://www.youtube.com/watch?v=Qr0-7Ds79zo); that was a joke.\n\n#### Author’s postscript\n\nIts real name is\n[Pineapple](https://en.wikipedia.org/wiki/Australian_fifty-dollar_note)\n[Häagen-Dazs](https://en.wikipedia.org/wiki/Ben_&_Jerry's).","body_html":"

How to speed up the Rust compiler in September 2026

\n

My last\npost\non the Rust compiler’s performance was two months ago and a lot has happened\nsince then.

\n

Overall progress

\n

The measurements for the period 2026-07-29 to 2026-09-28 can be seen\nhere.

\n

The 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”.

\n

rustdoc

\n

In my last post I mentioned how Noah Lev got some\nenormous speed wins on rustdoc. He recently wrote a\npost explaining in\nsome detail exactly how he did this. It’s an interesting and satisfying read.

\n

Clippy

\n

#159642: In this PR\nJakub Beránek enabled PGO for Clippy, giving\nwall-time improvements across most Clippy benchmarks, in the best case by 18%!

\n

LLVM update

\n

#158734: In this PR Nikita\nPopov upgraded the LLVM version used by the compiler\nto LLVM 23. As often happens when we upgrade LLVM, we saw some nice speedups.\nThe mean wall-time reduction across all benchmarks was 1.2%, which might not\nsound like much but is really impressive for a single PR. Great work from the\nLLVM folks!

\n

The new borrow checker

\n

The new borrow checker, Polonius\nAlpha (no relation to\nNapoleon\nDynamite), was\nenabled on\nNightly.\nIt is more precise than the existing borrow checker and accepts some valid\nprograms that the old borrow checker would reject. It does do more work than the\nold borrow checker, enough to make a measurable difference to compile time in a\nminority of cases, including the popular serde crate. Fortunately, Jack\nHuey has been on the case.

\n

#161938: In this PR Jack made\nsome liveness computations lazy, which reduced instruction counts for serde\nby 3-5%, and for some other benchmarks by less than 1%.

\n

#163027: In this PR Jack\nadjusted a data structure and tweaked some inlining, for mostly sub-1%\ninstruction count reductions across numerous benchmarks.

\n

There 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.

\n

The new trait solver

\n

The new trait solver,\nPenelope\nHammertime,\n[Ed. note: is that right?] was also enabled on\nNightly.

\n

As I said, a lot has been happening.

\n

Like the new borrow checker, the new trait solver is slower in a minority of\ncases. Jana Dönszelmann wrote a detailed\npost about the efforts to\nimprove the performance of this new solver.

\n

Jana’s post is detailed enough that I won’t say much more about the large\namount of ongoing work on the new solver, but I will mention in passing the PRs\nI made:\n#160479,\n#160605,\n#160801,\n#160892,\n#161077,\nand #161211.\nSome of these reduced compile times greatly for certain outlier crates: 50%\nhere, 25% there, 15% there, and even\nmore\non one stress test. And I am not the only one who has made progress here… go\nread Jana’s post.

\n

xmakro

\n

New contributor xmakro continued their run of good\nimprovements.

\n

#157281: In this PR xmakro\noptimized impl handling when building the specialization graph. This gave a\nmean cycle count reduction of 1.58% across all benchmarks, which is huge for a\nsingle PR.

\n

#158059: In this PR xmakro\noptimized one aspect of the loading of incremental compilation data, reducing\ninstruction counts across multiple benchmarks, in the best case by 6%.

\n

#160473: In this PR xmakro\navoided some allocations in a hot obligations processing path, reducing\ninstruction counts across numerous benchmarks, in the best case by 2%.

\n

#160268: In this PR xmakro\navoided a lot of allocations by changing the old/new trait solver selection\ncode to use static dispatch instead of dynamic dispatch. This gave mostly\nsub-1% instruction count reductions across a number of benchmarks. This hot\nallocation path had been showing up in profiles for a while and I had earlier\ntried exactly the same idea in\n#155714. But I got regressions\non a couple of benchmarks, possibly due to slightly different choices of where\nto place some #[inline] attributes. It was good to see this obvious\ninefficiency fixed.

\n

Dataflow analysis

\n

#160193: In this PR I changed\nthe CFG traversal algorithm used by the dataflow analyses in the compiler.\nThese analyses iterate to a fixpoint and the traversal algorithm can affect how\nquickly the fixpoint is reached. For most code the new algorithm makes no\ndifference, but the cranelift-codegen crate has one enormous function with\nover 18,000 basic blocks. The old algorithm required 1.5 million calls to\napply_effects_in_block to reach a fixpoint for the EverInitializedPlaces\nanalysis used by the borrow checker; the new algorithm requires 90,000. This\ngave an enormous ~30% wall-time reduction for a check build of this crate.

\n

#160033: In this PR I made\nEverInitializedPlaces more efficient again, this time by not tracking\nunnecessary data for projections. This reduced instruction counts on the\nmatch-stress benchmark by 17%, and on a few other benchmarks by less than 1%.

\n

LLMs

\n

They’ve gotten very good at certain kinds of analysis. I’m still writing all my\nown code and text, because (a) that’s paramount, and (b) the project\npolicy requires it, but I\nhad useful LLM analysis assistance on several of the PRs mentioned in this post.

\n

Anyway, enough about that.

\n

Miscellaneous

\n

#160535: In this PR Chris\nDenton increased the default stack size used\nby the compiler, which allowed the removal of ensure_sufficient_stack, a\nmanual stack extension mechanism sprinkled about in places prone to high levels\nof recursion. There was a lot of discussion about this one because it can be\ndifficult to decide how to best deal with stack exhaustion. But the performance\neffects are clear, with reduced instruction counts across many benchmarks, in\nthe best case by almost 3%.

\n

#160506: The project uses a\nlot of “rollup” PRs, where multiple PRs are merged together. This is because we\ndon’t have sufficient CI capacity to merge every PR individually. Normally PRs\nthat affect performance are merged by themselves so we can measure their\neffects clearly. For the first time ever, at one point we had so many\nperformance improvement PRs waiting in the merge queue that Jonathan\nBrouwer created a rollup containing 10\nperformance-improving PRs to keep things moving! This is a good problem to\nhave. And later on we had\n#162859 which contained four\nperformance-improving PRs. (You needn’t worry about unexpected effects slipping\nin because we have the ability to run the perf benchmark suite on the\nindividual PRs after merging, to make sure each PR had the expected performance\neffect.)

\n

#162747: In this PR I made\nsome minor improvements to the code that lowers AST to HIR. It was a cleanup\nthat wasn’t expected to affect performance but it reduced instruction counts\nacross numerous benchmarks, in the best case by 1.5%. Sometimes you get lucky.

\n

Job status

\n

Tomorrow I will start working at Hexcat on the compiler\nperformance\noptimizations\nproject goal. It’s exciting! Many thanks to Mara Bos, Predrag Gruevski, and all\nthe other people who helped make this happen.

\n

Editor’s postscript

\n

The new solver’s name is not\nPenelope\nHammertime; that was a joke.

\n

Author’s postscript

\n

Its real name is\nPineapple\nHäagen-Dazs.

","headings":[{"level":1,"text":"How to speed up the Rust compiler in September 2026","id":"how-to-speed-up-the-rust-compiler-in-september-2026"},{"level":2,"text":"Overall progress","id":"overall-progress"},{"level":2,"text":"rustdoc","id":"rustdoc"},{"level":2,"text":"Clippy","id":"clippy"},{"level":2,"text":"LLVM update","id":"llvm-update"},{"level":2,"text":"The new borrow checker","id":"the-new-borrow-checker"},{"level":2,"text":"The new trait solver","id":"the-new-trait-solver"},{"level":2,"text":"xmakro","id":"xmakro"},{"level":2,"text":"Dataflow analysis","id":"dataflow-analysis"},{"level":2,"text":"LLMs","id":"llms"},{"level":2,"text":"Miscellaneous","id":"miscellaneous"},{"level":2,"text":"Job status","id":"job-status"},{"level":3,"text":"*Editor’s postscript*","id":"editor-s-postscript"}]}}