Rustコンパイルの深淵：LTOとCodegen-unitsが握る「最適化の限界点」を制御する
Rustのコンパイル速度と実行パフォーマンスは、単なるトレードオフの関係ではない。それは、「LLVMの最適化エンジンの射程距離をどこまで広げるか」という設計思想の問題だ。
多くのエンジニアがデフォルトの `cargo build –release` に甘んじているが、大規模なプロダクトでは、この設定一つでCIのコストが数倍に膨らむか、あるいは実行時のレイテンシが数十ミリ秒削れるかが決まる。本稿では、Rustツールチェーンの心臓部に触れ、コンパイラを飼い慣らすための戦略的チューニングを伝授する。
—
1. LTOとcodegen-unitsの「物理的」な真実
Rustのコンパイル速度を支配する最も重要な二つのパラメータがある。`lto` と `codegen-units` だ。
Link Time Optimization (LTO) の真価
デフォルトのLTOは「各クレート単位」で完結する。しかし、`lto = “fat”` を指定すると、LLVMは全クレートを跨いでインライン展開やデッドコード除去を行う。
- メリット: 境界を越えた最適化により、関数呼び出しのオーバーヘッドがゼロに近いレベルまで消滅する。
- リスク: リンカに渡す中間表現（IR）が巨大化し、リンク時間が指数関数的に増大する。
Codegen-units: 並列性の代償
`codegen-units` は、コンパイル時にコードをいくつの塊に分割するかを決める。
- デフォルト (`16`): コードを16分割して並列処理するため、コンパイルは速いが、各ユニット間の最適化（インライン展開など）が制限される。
- 最適化特化 (`1`): 全体を一つの塊として扱うため、LLVMはコード全体を見渡して最高の最適化を施せるが、並列度が落ちるためビルド時間は最大化する。
—
2. 実務で「震える」ための設定ベストプラクティス
プロダクトの特性に応じて、`Cargo.toml` を以下のように最適化すべきだ。
プロファイル設定の最適化構成例
[profile.release]
1. 実行速度を極限まで引き出すための設定 (本番用)
opt-level = 3 # 最適化レベルを最大に
lto = “fat” # 全クレートを跨いだ全域最適化を有効化
codegen-units = 1 # ユニットを1つに集約し、最適化の余地を最大化
panic = “abort” # パニック時のスタックアンワインドコードを削除しバイナリ軽量化
2. 開発効率を最優先する設定 (ローカル開発用)
[profile.dev]
opt-level = 0 # 最適化せず、コンパイル時間を短縮
debug = true # デバッグ情報をフル装備
3. 実行速度とビルド時間のバランスを取る設定 (CI/CD用)
[profile.release-ci]
inherits = “release”
codegen-units = 16 # 並列度を確保し、ビルド時間を短縮
lto = “thin” # “fat”よりは軽いが、局所的な最適化は維持
なぜ `panic = “abort”` なのか？
デフォルトの `unwind` は、パニック時にスタックを巻き戻すためのメタデータをバイナリに埋め込む。これはバイナリサイズを肥大化させ、CPUの命令キャッシュ効率を微妙に下げる。サーバーサイドのサービスであれば、即座に終了させてKubernetes等のオーケストレーターに再起動を任せるのが、モダンな「落ちる前提のインフラ」に対する最適解だ。
—
3. 生産性を劇的に高める「テックリードの隠し味」
.cargo/config.toml によるチーム開発の平準化
個人の環境に依存せず、チーム全員が同じビルド設定を共有するために、リポジトリルートに `.cargo/config.toml` を配置せよ。
.cargo/config.toml
[target.x86_64-unknown-linux-gnu]
リンカに mold を指定してリンク速度を劇的に高速化
moldは金田浩太朗氏が開発した超高速リンカ。LTO有効時のリンク待ち時間を数分から数秒に短縮する
rustflags = [“-C”, “link-arg=-fuse-ld=mold”]
※ `mold` はLinux環境であれば間違いなく導入すべき神ツールだ。
必須のVS Code神プラグイン
1. rust-analyzer: 言うまでもないが、設定で `procMacro.enable` を常に真にしておくこと。
2. Cargo Helper: Cargo.tomlの編集を支援する。
3. Error Lens: コンパイルエラーをエディタ上に直接表示させる。エラーが出るたびにターミナルへ視線を移す時間をゼロにするだけで、思考の文脈が維持される。
開発速度を上げるショートカット
- `cargo check` の常駐: ターミナルで `cargo watch -x check` を走らせ、コードを保存するたびにバックグラウンドで型チェックを走らせる。これだけで「コンパイル待ち」という名目の休憩時間が消滅する。
—
4. アーキテクトからの提言：計測なき最適化は「悪」である
最後に、最も重要なことを伝える。「直感でビルド設定をいじるな」。
必ず `hyperfine` を使って、最適化前後の実行速度とビルド時間を計測すること。
実行速度の計測コマンド例
hyperfine –warmup 3 ‘target/release/my-app’
LTOを有効にして「3秒速くなった」としても、そのために「CIが5分長くなった」のであれば、それはチーム全体の生産性を著しく低下させている。最適化の基準は、常に「開発体験（DX）」と「実行効率」のバランス点にある。
今日から、プロジェクトのビルド時間は「コスト」ではなく「戦略的投資」として管理し、ツールチェーンを支配するアーキテクトとしての誇りを持ってコードを書いてほしい。それが、世界最高峰のエンジニアリングへの第一歩だ。