In den letzten zwei Monaten hat das Rust-Compiler-Team erhebliche Arbeit geleistet, und die Daten spiegeln dies wider. Vom 29. Juli bis zum 28. September wurden 629 Benchmark-Durchläufe erfasst, wobei die durchschnittliche Zeitersparnis bei 4,57 % lag. Der eigene Bericht des Teams beschreibt dies als einen deutlichen Leistungsgewinn innerhalb dieses kurzen Zeitraums.
Das Dokument mit dem Titel „Wie man den Rust-Compiler im September 2026 beschleunigt“, verfolgt die zahlreichen wechselnden Komponenten des Compilers, vom Werkzeug, das Borrowing prüft, bis hin zum System, das Traits auflöst, bis hin zum Dokumentationsdienstprogramm rustdoc. Das Ergebnis wird mit dem Begriff „ein Meer von Grün“ beschrieben: die meisten Leistungstests zeigten Fortschritte, während nur eine kleine Anzahl in die entgegengesetzte Richtung verlief.
Rustdoc Wins
Rustdoc, das Werkzeug, das die Dokumentationsseiten von Rust erstellt, hat von Noah Lev einige wesentliche Geschwindigkeitsverbesserungen erhalten. Er hat einen gründlichen Bericht über seinen Ansatz verfasst, und das Team beschreibt die Lektüre als „interessant und befriedigend“ und weist darauf hin, dass die Arbeit das Werkzeug deutlich schneller gemacht hat.
Jakub Beránek brachte PGO (Profile-Guided Optimization) zu Clippy, und dieser Schritt lieferte große Fortschritte in der tatsächlichen Laufzeit über fast alle Clippy-Benchmarks. Der größte einzelne Fortschritt war eine Verbesserung von 18 %.
Das LLVM-Upgrade
Die LLVM-Version des Compilers wurde dank Nikita Popows Upgrade auf LLVM 23 aktualisiert. Solche Upgrades liefern typischerweise Leistungsgewinne, und dieses Mal reduzierte es die durchschnittliche tatsächliche Laufzeit über alle Benchmarks um 1,2 %. Der Bericht bezeichnet dieses Ergebnis als wirklich bemerkenswert für einen einzelnen Pull Request.
Polonius und Penelope
Der neue Borrow Checker, Polonius, ist auf Nightly eingetroffen. Er bietet eine größere Präzision als sein Vorgänger und akzeptiert bestimmte gültige Programme, die der alte Checker ablehnen würde. Er übernimmt auch mehr Arbeit, was in einer Minderheit von Fällen die Kompilierzeit merklich verlängert, einschließlich der weit verbreiteten serde-Kiste.
Jack Huey nahm sich der Problematik an und machte die Lebensdauerberechnungen lazy anstatt immediate, was die Instruktionsanzahl für serde um 3-5 % und für einige andere Benchmarks um weniger als 1 % reduzierte.
Huey nahm Anpassungen an einer Datenstruktur vor und führte einige Inline-Änderungen durch, was zu einer Reduzierung der Instruktionsanzahl unter 1 % über zahlreiche Benchmarks führte.
Nightly hatte auch Penelope Hammertime, den neuen Trait-Solver, aktiviert. Genau wie Polonius läuft er in einem kleinen Teil der Fälle langsamer. Jana Dönszelmann veröffentlichte einen ausführlichen Bericht über die Arbeit, die darauf abzielt, dies zu beschleunigen.
Das Dokument listet eine Reihe von Pull Requests auf, die vom Autor zusammengetragen wurden: #160479, #160605, #160801, #160892, #161077 und #161211. Einige dieser Änderungen reduzierten die Build-Zeit deutlich für bestimmte Crates, die langsam zu kompilieren waren: 50 % in einem Fall, 25 % in einem anderen und 15 % an anderer Stelle, wobei ein Stresstest sogar eine noch größere Reduktion zeigte.
xmakros Run
xmakro hielt ihre Serie starker Beiträge mit einer weiteren Verbesserung aufrecht. Diesmal optimierten sie, wie impls während der Konstruktion des Spezialisierungsgraphen behandelt werden, und das Ergebnis war eine durchschnittliche Reduktion der Zyklusanzahl von 1,58 % über alle Benchmarks hinweg. Das ist ein signifikanter Gewinn durch einen einzelnen Pull Request.
Das Laden von Daten für inkrementelle Kompilierung wurde durch xmakros Arbeit effizienter gestaltet, was die Instruktionsanzahl über mehrere Benchmarks hinweg reduzierte, wobei die dramatischste Reduktion bei 6 % lag. Eine separate Änderung entfernte einige Allokationen aus einem häufig verwendeten Pfad zur Verarbeitung von Obligations, was ebenfalls die Instruktionsanzahl über viele Benchmarks hinweg senkte, wobei die größte Verbesserung 2 % erreichte.
xmakro wechselte den alten/neuen Trait-Solver-Auswahlcode von dynamischer zu statischer Dispatch um. Diese Änderung lieferte größtenteils Instruktionsanzahlenreduktionen unter 1 % über mehrere Benchmarks hinweg. Der Hot-Allocation-Pfad war bereits seit einiger Zeit in Profilen aufgetaucht, und der Autor hatte bereits zuvor in #155714 versucht, den gleichen Ansatz anzuwenden.
Dataflow-Analyse
PR #160193 änderte den CFG-Traversierungsalgorithmus, der von den Datenflussanalysen des Compilers verwendet wird, die zu einem Fixpunkt iterieren und auf den Traversierungsalgorithmus angewiesen sind, um ihre Konvergenzgeschwindigkeit zu bestimmen.
In den meisten Fällen erzeugt der neue Algorithmus überhaupt keine Veränderung. Eine Ausnahme ist das cranelift-codegen-Crate, das eine einzelne riesige Funktion mit mehr als 18.000 Basiblocken enthält. Mit dem alten Ansatz erforderte das Erreichen eines Fixpunkts für die EverInitializedPlaces-Analyse, die vom Borrow Checker verwendet wird, 1,5 Millionen Aufrufe von apply_effects_in_block. Der neue Algorithmus reduziert diese Zahl auf 90.000, was eine dramatische Reduktion der „Wall-Time“ um etwa 30 % für einen Check-Build dieses Crates bedeutet.
Ein weiterer PR stellte EverInitializedPlaces später wieder effizienter dar, indem Daten nicht mehr verfolgt wurden, die nicht für Projektionen benötigt wurden. Diese Änderung reduzierte die Instruktionsanzahl im match-stress-Benchmark um 17 % und in einigen anderen Benchmarks um weniger als 1 %.
Stack Size und Rollups
Chris Denton erhöhte die standardmäßige Stack-Größe des Compilers, was es ermöglichte, ensure_sufficient_stack zu entfernen, ein manuelles Stack-Erweiterungsfeature, das über Orte verstreut war, an denen tiefe Rekursion wahrscheinlich war. Viel Gespräch drehte sich um diese Änderung, da die Entscheidung, wie Stack-Erschöpfung zu handhaben ist, nicht immer einfach ist.
Die Ergebnisse zeigen echte Gewinne, mit weniger benötigten Instruktionen über eine breite Palette von Tests, wobei einige eine Reduktion von fast 3 % zeigen.
Das Projekt verwendet auch viele „Rollup“-PRs, bei denen mehrere PRs zusammengeführt werden. Dies liegt daran, dass das Team nicht über ausreichende CI-Kapazität verfügt, um alles separat zusammenzuführen.
Der LLM-Assistent
Mehrere der in dem Beitrag referenzierten PRs profitierten von der Unterstützung der LLM-Analyse, die der Autor hilfreich fand. Diese Systeme haben sehr viel Geschick in bestimmten Formen der Analyse entwickelt, obwohl sie vollständig autark bleiben, wenn es darum geht, ihren eigenen Code und Text zu schreiben. Diese Unabhängigkeit ist von größter Bedeutung und entspricht auch der ausdrücklich formulierten Richtlinie des Projekts.
Die abschließende Aussage des Berichts besagt, dass der „See of Green“ zeigt, wie die Polonius Alpha-Regressionen unter all den anderen jüngsten Verbesserungen untergegangen sind.
Was das bedeutet
Die Größe des Projekts definiert dessen Umfang. Sechsundzwanzig Benchmark-Tests, eine durchschnittliche Reduzierung der Wandzeit von 4,57 %, 555 Verbesserungen von 629 insgesamt – das sind beträchtliche Zahlen. Das Compiler-Team hat echte, messbare Fortschritte über Dutzende von PRs erzielt, wo Erfolge die Verluste überwogen.
Das Dokument beschreibt eine Gruppe, die Höchstgeschwindigkeit fährt, und zwar als einen unkomplizierten Bericht und nicht als ein Werbe-Material. Es enthält Geständnisse von Misserfolgen, wie etwa der vorherige Versuch mit statischer Dispatch in #155714, der zu Regressionen führte, neben Berichten über Erfolge. Diese Offenheit trägt zur Stärke des Dokuments bei.
Sowohl die Polonius- als auch die Penelope-Erzählungen bieten nützliche Lehren. Jede dieser neuen Methoden ist in manchen Situationen langsamer, aber beide werden mit konzentrierter Anstrengung verfeinert. Das Serde-Crate-Problem wurde beispielsweise durch Jacks Hueys lazy Liveness-Berechnungen gelöst.
Ein Compiler ist ein kompliziertes Stück Mechanik, und ihn zu beschleunigen erfordert die Änderung fast aller seiner Teile. Über zwei Monate hat das Team diese Arbeit geleistet, und die Ergebnisse sind sichtbar. Das „Meer des Grüns“ ist mehr als nur ein Ausdruck – es stammt von Hunderten von Benchmark-Tests, die durchgeführt wurden, um die Verbesserungen zu messen.
Der abschließende Hinweis deutet auf weitere Fortschritte beim Trait-Solver hin, wobei Janas Dönszelmanns ausführlicher Bericht zitiert wird. Dies impliziert, dass das Tempo aufrechterhalten wird.
| Datumsbereich | Benchmark-Läufe | Mittlere Reduzierung der Wandzeit |
|---|---|---|
| 2026-07-29 bis 2026-09-28 | 629 | 4.57% |
Ein klares Bild ergibt sich von einer Gruppe, die ihr Handwerk versteht, wobei der Compiler effizienter wird und seine Erbauer ihre Bemühungen sorgfältig dokumentieren.
Quellenmaterial: „Wie man den Rust-Compiler im September 2026 beschleunigt“, nnethercote.github.io.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.