「Rustの長いコンパイル時間が生産性を低下させている」 Rustプロジェクトが公式調査結果を公開：ビルドパフォーマンスに対する満足度は10段階中「6」

Rustプロジェクトは公式ブログで、2025年夏に実施した「Rust Compiler Performance Survey」（Rustコンパイラパフォーマンス調査）の結果を報告した。

[＠IT]

　プログラミング言語「Rust」を開発するRustプロジェクトは2025年9月10日（米国時間）に公式ブログで、2025年夏に実施した「Rust Compiler Performance Survey」（Rustコンパイラパフォーマンス調査）の結果を報告した。

　この調査は、Rustプロジェクトのコンパイラパフォーマンスワーキンググループが、Rustのビルドパフォーマンスに関する開発者の最大の悩みを理解することを目的に実施し、3200件以上の回答を得た。Rustプロジェクトは以下の構成で、今回の調査結果を報告するとともに、Rustコードのビルドパフォーマンス向上のために最近実施した取り組みを紹介している。

全体的な満足度「長いコンパイル時間が生産性を低下させている」

　Rustのビルドパフォーマンスに対する満足度は、10段階評価（1＝低い、10＝高い）によると平均「6」で、最も回答が多かった評価は「7」だった。

Rustのコンパイルパフォーマンスにどの程度満足しているか（提供：Rustプロジェクト）

　この結果から、Rustのビルド体験はユーザーやプロジェクトによって大きく異なることが分かる。調査結果では、Rustのビルドパフォーマンスの過去数年間における大幅な改善を評価する声や「『C++』と比較して遜色ない」「C++より優れている」という肯定的な意見が多かった一方で、「『Go』や『Zig』のような言語と比べて遅い」という指摘や、「長いコンパイル時間が生産性を著しく低下させている」という意見もあった。実際、「Rustをもう使用していない」と答えた回答者の約45％が、その理由の一つとして、コンパイル時間の長さを挙げている。

主な課題となるワークフロー

　調査結果によると、ビルドに関して特に問題視されたのは以下の3つだ。

• インクリメンタル再ビルド
• 型チェック（cargo check）とIDE（統合開発環境）内でのリアルタイム解析
• クリーンビルドとCI（継続的インテグレーション）ビルドのパフォーマンス

インクリメンタルリビルドの待ち時間

　自由回答で圧倒的に多くの苦情が寄せられたのは、ソースコードの小規模な変更後のインクリメンタル再ビルドを待つ時間の長さだ。多くの開発者は型チェックやコードエディタでのインライン注釈を利用するので、コード変更のたびにこの遅延を経験しているわけではない。だが、回答者の55％が、「コード変更後のリビルドの待ち時間は10秒以上」と答えている。

コード変更後にコンパイラがコードを再ビルドするまでの待ち時間はどのくらいか（提供：Rustプロジェクト）

　インクリメンタル再ビルドに時間がかかる主な原因は以下の通り。

ワークスペースでの変更によって、不要な再コンパイルが発生する

　複数の依存クレートを持つクレートをワークスペースで変更し、再ビルドを実行すると、現状では、それら全ての依存クレートを再コンパイルする必要がある。

リンク処理が遅い

　リンク処理の遅さについての意見も多く挙がった。Rustプロジェクトはその理由として「Rustのコンパイラが外部のリンカー（リンク編集ツール）にリンク処理を委ねているからだ」と説明している。外部リンカーはOSやツールから提供されるものであり、Rustコンパイラはこれに対して指示を出し処理を依頼する形だ。このため、リンク処理の速度は外部ツールの性能に大きく依存することになる。

　この状況を改善するため、Rustプロジェクトはデフォルト（初期設定）のリンカーをより高速な「LLDリンカー」に切り替える予定だ。

単一クレートのインクリメンタル再ビルドが遅い

　インクリメンタル再ビルドのパフォーマンスは、Rustコンパイラのインクリメンタルエンジンの“賢さ”に依存する。ここでいう賢さとは「無駄な再コンパイルを避け、効率的に必要最小限の処理だけをする能力」のことだ。Rustプロジェクトは「Rustのインクリメンタルビルド機能は既に非常に高度だが、コンパイルの一部にはまだインクリメンタルに対応していない部分や、最適にキャッシュされていない部分がある」としている。

型チェックとIDEのパフォーマンス

cargo checkがcargo buildとビルドキャッシュを共有しない

　回答者の約60％が、コードの型チェック、ビルド、テストにターミナルコマンド「cargo」を使用している。中でも「cargo check」が最もよく使われるコマンドだ。cargo checkでは、実行可能ファイルを生成せず、コードがコンパイルできるかどうかを素早く確認できる。

　ただし、幾つか課題もある。よく指摘されるのは「cargo checkが『cargo build』とビルドキャッシュを共有しない」ということだ。そのために、例えば、全ての型エラーを見つけるために数回cargo checkを実行し、それが成功した後で、アーティファクトを生成するためにcargo buildを実行すると、追加のコンパイルが発生する。

コードエディタやIDEでの型チェックのレイテンシ

　回答者の約87％が、コンパイラエラーを検査する仕組みとして主にエディタのインライン注釈を使用しており、そのうち約33％が、これらの注釈の待ち時間を大きく問題視している。自由回答では、Rustのコーディング支援ツールである「Rust Analyzer」のパフォーマンスとメモリ使用量が、生産性の阻害要因だとの報告も多かった。

　Rust AnalyzerについてRustプロジェクトは「キャッシングシステムの改善やコンパイラの新しいトレイトソルバーの統合などにより、パフォーマンスを改善している」と説明している。

クリーンビルドとCIビルド

　回答者の約20％が「生産性の最大の阻害要因はクリーンビルドだ」と回答した。クリーンビルドが頻発する可能性がある領域にCIがある。1500人近くの回答者が、CIを通じてRustのコードをビルドしており、そのうち約25％が、CIビルドのパフォーマンスを大きく問題視している。だが、これらの回答者のほぼ36％が「CIではキャッシングを一切使用していない」と答えている。

　その理由として「ビルドで生成されるファイル群（ターゲットディレクトリ）が非常に大きく、CIプロバイダーの使用制限に抵触してしまう」といったことが理由として挙がった。

　Rustプロジェクトによると、最近、Cargoとコンパイラオプションに「-Zembed-metadata」という実験的機能を導入したという。これはターゲットディレクトリのサイズを縮小するように設計されている。また、定期的に不要なデータを自動削除する「ガベージコレクション」機能の実装も進んでいるという。

デバッグ情報

　ディスク使用量を大幅に削減するもう一つの方法は、生成されるデバッグ情報の量を削減することだ。

　デフォルトの「Cargo dev」プロファイルは、ワークスペースのクレートと全ての依存関係の両方について完全なデバッグ情報を生成する。これによって、デバッガでコードをステップ実行できるメリットが得られるが、ターゲットディレクトリのディスク使用量が増加し、コンパイルとリンクが遅くなってしまうというデメリットもある。

　回答者にデバッガの使用状況を尋ねたところ、以下の回答結果となった。

Rustコードをデバッグするためにどのくらいの頻度でデバッガを使っているか（提供：Rustプロジェクト）

　さらに、デバッグ情報をデフォルトで生成する必要があるかどうかを尋ねたところ、回答はばらついた。

最適化されていないビルドのデバッグ情報はデフォルトで必要か（提供：Rustプロジェクト）

　Rustプロジェクトのベンチマーク結果は、完全なデバッグ情報を生成するのではなく、「debuginfo」（デバッグ情報）のレベルを「line-tables-only」（バックトレースが動作するのに十分なdebuginfoのみを生成）にすると、20〜30％のパフォーマンス改善が可能であることを示している。デバッグ情報の生成を完全に無効にすると、改善はさらに大きくなる。

　ただし、「最適化されていないビルドのデバッグ情報はデフォルトで必要かどうか」の回答傾向からすると、Cargo devプロファイルのデフォルトを変更し、生成されるデバッグ情報を減らすと、デバッグ情報を必要としているユーザーにとっては不便になる一方、デバッグ情報があまり必要ないユーザーにとってはビルドが速くなる。つまり、あるユーザーのワークフローが改善する一方で、別のユーザーのワークフローは悪化することになる。

　RustプロジェクトのCargoチームは改善方法を検討している。例えば、Cargo devプロファイルで生成されるデバッグ情報を削減し、デバッグ用の新しい組み込みプロファイルを導入することだ。

ビルドパフォーマンスの改善策の認識と実施状況

　Rustのビルドパフォーマンスは、ビルドシステム（通常はCargo）とRustコンパイラの設定に加え、クレートの構造や使用されるソースコードパターンなど、さまざまな側面に影響される。そのため、ビルドパフォーマンスの改善には幾つかのアプローチが利用できる。例えば、異なる設定オプションの使用や、ソースコードの構造変更などだ。

　そこで回答者に対し、それらの改善策を知っているかどうか、試したことがあるかどうか、どの程度効果的だったかを尋ねたところ、以下のことが分かった。

• ビルドパフォーマンスを改善するための最も人気のある（そして効果的な）メカニズムは、依存関係の数とアクティブ化された機能を削減することと、大きなクレートを小さなクレートに分割することだ
• ソースコードの変更なしでビルドパフォーマンスを改善する最も一般的な方法は、代替リンカを使用することだと思われる。特に、moldとLLDが非常に人気があるようだ

　Rustプロジェクトは今回の調査結果を踏まえ、ビルドパフォーマンスを最適化するための公式ガイドの作成を決めている。このガイドの目的は、ビルドパフォーマンスを改善するためのさまざまなメカニズムについての認識を高め、それらのメカニズムに伴うトレードオフを評価するためのフレームワークを提供することだ。

ビルドが遅い理由を理解する

　ビルドが遅い場合、コンパイルプロセスが具体的にどこで時間を費やしているか、何がボトルネックである可能性があるかを特定することは難しい。今回の調査結果から、ビルドをプロファイリングするためのツールを活用している開発者は、非常に少ないことが明らかになった。

　現在、Cargoとrustcのパフォーマンス特性を直感的に理解する方法はあまり多くない。一部のツール（cargo build --timingsなど）は、限られた量の情報しか提供していない。また、「-Zself-profile」など、コンパイラ内部の知識なしには出力の解釈が非常に困難なツールもある。

　この状況を多少なりとも改善するため、Rustプロジェクトは、クレートのコンパイルにおけるボトルネックの可能性について、より多くの情報を提供する目的で、argo build --timingsの出力でリンク時間の表示をサポートしたとRustプロジェクトは述べている。

このニュースのポイント

Q: コンパイルパフォーマンスへの全体的な満足度は？

A: 平均は10段階評価で「6」、最多は「7」。一部でC++と同等または優れているとの声がある一方、GoやZigに比べ遅いとの不満も多く、長いコンパイル時間がRustを使わなくなった理由になったケースもある。

Q: 主な課題とされたワークフローは？

A:

• インクリメンタル再ビルド（小規模変更後でも10秒以上待たされるケースが多い）
• 型チェックとIDEの応答遅延
• クリーンビルドとCIビルドのパフォーマンス（約20％が最大の阻害要因と回答）

Q: インクリメンタルビルドのボトルネックは何か？

A: ワークスペース変更で不要再コンパイルが発生すること、外部リンカー依存によるリンク遅延、単一クレートのキャッシュ非最適化。改善策としてデフォルトを「LLDリンカー」に切り替え予定。

Q: 型チェックとIDEの課題は？

A: cargo checkがcargo buildとキャッシュを共有しないため追加コンパイルが発生。エディタ注釈の遅延やRust Analyzerのパフォーマンス不足も問題視されている。

Q: CIやデバッグに関する課題は？

A: CI利用者25％がビルド遅延を深刻視。ターゲットディレクトリが巨大でキャッシングが困難。改善策として「-Zembed-metadata」やガベージコレクション機能導入。デバッグ情報を減らすことで20〜30％改善可能だが、ユーザーごとの利便性に差が出る。