2026年9月にRustコンパイラを高速化する方法

元記事: 2026年10月1日原文(nnethercote.github.io)

概要

Rustコンパイラのパフォーマンスが過去2ヶ月で大幅に向上
多数のベンチマークで「sea of green」と呼ばれる好結果
rustdoc、Clippy、LLVM、Polonius Alphaなど各所で最適化
新しいトレイトソルバーやデータフロー解析でも改善
Hexcatでの新しいプロジェクト開始予定

Rustコンパイラのパフォーマンス進捗

期間2026-07-29から2026-09-28の平均ウォールタイム4.57%削減
629件のベンチマーク中555件が改善、74件のみが悪化
二桁％の改善を記録したベンチマークも複数
技術用語で「 sea of green」と呼ばれる好結果

rustdocの高速化

Noah Levによる大幅な rustdoc のスピードアップ
詳細な手法は本人の投稿で解説
読み応えと満足感のある内容

Clippyの最適化

Jakub Beránekが Clippy でPGOを有効化（PR #159642）
ほとんどのClippyベンチマークでウォールタイム改善
最大18%の高速化を達成

LLVMのバージョンアップ

Nikita Popovがコンパイラの LLVM をバージョン23にアップグレード（PR #158734）
全ベンチマーク平均で1.2%のウォールタイム短縮
単一PRとしては非常に優秀な成果

新しいボローチェッカー Polonius Alpha

Nightlyで Polonius Alpha （新ボローチェッカー）を有効化
旧ボローチェッカーよりも精度向上
一部ケースでコンパイル時間増加も、Jack Hueyの最適化で軽減
- PR #161938: liveness計算のlazy化でserdeなどの命令数3-5%削減
- PR #163027: データ構造調整とインライン化で複数ベンチマークで微小改善
全体の改善が多く、Polonius Alphaの悪化も相殺

新トレイトソルバー Pineapple Häagen-Dazs

Nightlyで新トレイトソルバー Pineapple Häagen-Dazs を有効化
一部ケースで速度低下も、Jana Dönszelmann等による継続的な改善
著者自身も複数のPRで大幅な高速化を実現
- 例: 特定crateで50%、25%、15%、さらに高い改善

xmakroによる最適化

新規貢献者 xmakro による一連のパフォーマンス改善
- PR #157281: specialization graph構築時のimpl処理最適化で1.58%短縮
- PR #158059: インクリメンタルコンパイルデータ読み込みの最適化で最大6%短縮
- PR #160473: obligations処理経路のアロケーション削減で最大2%短縮
- PR #160268: trait solver選択のstatic dispatch化で複数ベンチマーク微小改善

データフロー解析の改善

PR #160193: データフロー解析のCFG走査アルゴリズムを変更
- cranelift-codegen crateで~30%のウォールタイム削減
PR #160033: EverInitializedPlacesの無駄なデータ追跡を排除し、match-stressベンチマークで17%の命令数削減

LLM（大規模言語モデル）の活用

一部PRで LLM による分析支援を活用
コード・テキストは原則自作、プロジェクト方針に従う

その他の改善

PR #160535: Chris Dentonがデフォルトスタックサイズ拡大、手動スタック拡張の削除で最大3%命令数削減
PR #160506, #162859: 複数パフォーマンス改善PRをまとめてロールアップ、効率的なマージ運用
PR #162747: ASTからHIRへの変換コードのクリーンアップで最大1.5%命令数削減

新しい職務と感謝

明日より Hexcat でコンパイラパフォーマンス最適化プロジェクト始動予定
Mara Bos、Predrag Gruevski他関係者への謝意

編集後記

新トレイトソルバー名「Penelope Hammertime」は冗談、本当の名前は「 Pineapple Häagen-Dazs」

提供: ハクソク · 要約更新: 2026年10月2日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

そもそも、コンパイラが遅いのはなんでなんだろう？俺はRustの知識が全然ないんだけど、遅いってどのくらい遅いの？Cのコンパイラと比べてどうなの？パフォーマンスの悪化の原因は何？

└

C++のコンパイラと似たようなもんで、理由は一つじゃないよ。すごく最適化を試みる言語だし、大きな言語だから、安全性チェックもあるし、llvmを使ってるからちょっと遅いし、ジェネリクスを使うから余分なコードが生成されるし、色々あるよね。

└

他の多くの言語がコンパイル時にやらない静的解析をしてるんだよ。

└

まず、この記事が「Rustコンパイラのスピードアップ」について話してるからって、コンパイラが「遅い」とは限らないよね。じゃあ、rustcは例えばclangより遅いの？どのくらい？なんで？それは別の（しかも複雑な）質問だよ。何をコンパイルするかによるけど、rustcは1〜5倍遅いこともあるかも（時にはもっと遅いかも？）。理由はいろいろあるけど、一般的にRustのコンパイルが遅いのは、コンパイラがCと比べてやることが多いから（モノモーフィゼーション、複雑なトレイト解決＋型推論、借用チェッカー...）。「遅い」という言葉は、具体的な基準がないとこの文脈では意味がないとも言えるね。

└

何かをするのはタダじゃないよ。例えば、Goは現代の言語としては比較的早くコンパイルされるけど、その最大の理由は他のコンパイラよりもやることが少ないから...最適化が少ないし、チェックも少ないし、ファイルをコンパイルするためにたくさんのヘッダーを読む必要がないように言語に組み込まれてる部分もあるけど、要するに、良い意味でも悪い意味でも、やることが少ないのが鍵なんだ。Rustみたいに保証やチェックがたくさんあるものが欲しいなら、それなりに時間がかかるよ。マクロやモノモーフィゼーション、トレイトを使った暗黙のコード生成なども影響してるしね。そういうチェックを実装するのに、常にO(n)やO(n log n)のコードが得られるわけじゃない。もしかしたらスピードアップできるかもしれないし、ちょっとしたトリックがあるかもしれないけど、パレートのフロンティアでは、チェックが多い言語は少ない言語よりもコンパイルが遅くなるんだ。それはRustの欠点じゃなくて、そういうもんなんだよ。

└

ゼロコストの抽象化は、コンパイル時間においてゼロコストじゃないよ。高レベルの抽象化は、コンパイラが最適化しなきゃいけないたくさんのボイラープレートに変換されるんだ。最適化されてないビルドでは、リンク時がボトルネックになることが多い。Rust/Cargoはほとんどのビルドを並列化できて、たくさんのコードやデバッグ情報を生成するけど、結局、リンクする時に一気にそれを処理しなきゃいけないんだ。オブジェクトや実行ファイルのフォーマットは古い時代に設計されたから、インクリメンタルにビルドしたり並列でビルドするのが難しいんだ（いくつかのリンカーは試みてるけど）。

└

なんでダウンボートされてるのか分からないな。

└

昔聞いたことがあるんだけど（今もそうかは分からないけど）、コンパイル時間の一番のボトルネックはマクロとコード生成だって。どっちもRustコンパイラの影響外だし。マクロはめちゃくちゃ複雑になり得るから、頼んだ分だけコストがかかる。コード生成はLLVMで、これは固定された選択肢だね。Craneliftを使えば回避できるけど、他のところでコストがかかるし。あと、ジェネリクスやモノモーフィゼーションもよく話題に上がるけど、C++みたいな他の言語に比べて追加の静的解析のコストが大きな要因ではないっていうのが一般的な見解みたい。とはいえ、コンパイラのパフォーマンス改善が見られるのは嬉しいよね。協力しないと恩恵を受けられないかもしれないけど（例えば、マクロを軽く保ったり、ジェネリクスを減らしたり）。

└

結局、コンパイル時間がRustの重要な機能の設計時に一級の考慮事項じゃなかったってことが問題なんだよね。その影響を軽減するためにできることは限られてる。

└

これをzigと比べてみて。zigではコンパイラの性能が非常に重要で、それが言語設計に影響を与えてるんだ。zigとGoはその点で似てるね。

大企業からオープンソースのメンテナーへの寄付が、Rustの体験に実際に影響を与えてるのを見ると嬉しいね。これらの企業に、従業員がコンパイル待ちで5%少ない時間を使ってるって伝えたら、Nickや他の人たちへの将来の投資を促すかもしれないね。

借用チェッカーを改善して、以前は引っかかってたコードを検証しても、5%のスピードアップが実現できたのは本当に素晴らしいね。時には、両方手に入れることもできるんだな。

Hacker Newsで議論の続きを見る