Rust ビルド可視化ツール

(danielchasehooper.com)

20 ポイント投稿者 GN⁺ 2025-08-16 | まだコメントはありません。 | WhatsAppで共有

紹介と背景

What the Forkは単なるシステムプロファイラではなく、ビルドに特化した問題を診断するツール
例として、make 使用時の -j フラグ未使用、特定ファイルまたはコンパイル段階への時間偏重、並列実行可能なのに逐次実行されているコマンドの検出などがある
特に CI 環境における clean build の性能分析と最適化に効果的
使い方は wtf コマンドをビルドコマンドの前に付けて実行するだけ（例: wtf make、wtf cargo build、wtf npm run build など）
ビルドが始まると UI が起動し、各プロセスの進行状況をリアルタイムで更新する

ビルドは複数のプロセス（例: bash、clang、ld）の組み合わせで成り立つ
大規模ビルドでは cargo、make、bazel、gradle、xcodebuild など多様なビルドツールが使われ、これらは実際には多数のコマンド、依存関係、キャッシュ、スケジューリング処理を実行している
ターミナル出力だけでは、ネストされたプロセス（例: clang が内部で呼び出す ld など）や詳細なタイミング構造を把握できない
そのため、OS ごとのプロセス開始・終了を検知するシステムコール（macOS: Endpoint Security API、Linux: ptrace()、Windows: Event Tracing for Windows など）を活用する
この方式により、ビルド全体の過程とタイムラインを復元し、各段階の実行経路と所要時間を識別できる
ビルド以外にも、さまざまなサブプロセスのトラッキングに活用できる

複数のエンジニア（Delta、Mozilla、Apple 所属）が実際にプロジェクトへ適用した結果、予想外の問題を発見
例 1: Cargo を使うオープンソースプロジェクトで、ファイルが逐次的にコンパイルされており、並列性不足を確認（10 コア CPU で 10 倍以上の高速化可能性を確認）
例 2: Ninja を使った LLVM ビルドでは、すべての CPU コアが効率よく並列処理を実行し、理想的なビルド効率を達成
例 3: CMake ベースのプロジェクトで、cmake/make/clang のネスト実行と Xcode/OS バージョン再確認が 85 回も繰り返される非効率な構造を発見（実際の作業はごく一部のみ）
例 4: xcodebuild を使う大規模 Objective-C プロジェクトでは、ビルド後半の並列処理不足と、ビルド開始前に 6 秒間のアイドル状態が存在することを確認（対して ninja は 0.4 秒後にすぐコンパイル開始）
例 5: Zig が Orca Project をコンパイルする際、依存関係のビルド順序がランダムに決まり、運によって並列処理効率が変化。一部の依存関係が最後に実行され、並列性が低下する現象を観察
例 6: make/go を使う GitHub CLI プロジェクトでは依存関係のダウンロード時間が長い。依存関係を減らせばビルド速度の改善が期待できる