Bazel のどのユーザーでも、予想よりも低速または遅いビルドが発生した可能性があります。個々のビルドのパフォーマンスを改善すると、次のような大きな影響を与えるターゲットに対して特に価値があります。
イテレーションと（再）ビルドが頻繁に行われるコア デベロッパー ターゲット。
共通ライブラリは他のターゲットに大きく依存します。
ターゲットのクラス（カスタムルールなど）の代表的なターゲットで 1 つのビルドの問題を診断、修正すると、より大規模な問題を解決できます。
ビルドのパフォーマンスを向上させる重要なステップは、リソースが消費される場所を理解することです。このページでは、収集されるさまざまな指標について説明します。ビルド パフォーマンスの内訳では、これらの指標を使用してビルドのパフォーマンスの問題を検出し、修正する方法について説明します。
Bazel ビルドから指標を抽出する主な方法には、次のようなものがあります。
Build Event Protocol（BEP）
Bazel は、Build Event Protocol（BEP）を介してさまざまなプロトコル バッファ build_event_stream.proto を出力します。このバッファは、指定したバックエンドで集計できます。ユースケースに応じて、さまざまな方法で指標を集計できます。ここでは、一般的に考慮されるコンセプトと proto フィールドについて説明します。
Bazel のクエリ / cquery / aquery コマンド
Bazel には、クエリ、cquery、aquery という 3 種類のクエリモードがあり、ユーザーはそれぞれターゲット グラフ、構成されたターゲット グラフ、アクション グラフをクエリできます。クエリ言語では、さまざまなクエリモードで使用できる関数スイートを使用し、ニーズに合わせてクエリをカスタマイズできます。
JSON トレース プロファイル
Bazel が呼び出されるたびに、Bazel は JSON 形式のトレース プロファイルを書き込みます。JSON トレース プロファイルは、Bazel が呼び出しに費やした時間をすばやく理解するのに便利です。
実行ログ
実行ログは、マシンや環境の違いや非決定的アクションに起因するリモート キャッシュ ヒットの欠落をトラブルシューティングし、修正するのに役立ちます。フラグ --experimental_execution_log_spawn_metrics（Bazel 5.2 から入手可能）を渡すと、ローカルで実行されるアクションとリモートで実行されるアクションの両方に関する詳細な指標が生成されます。これらの指標を使用して、ローカルとリモートのマシンのパフォーマンスを比較できます。また、スキュー実行のどの部分が予想よりも一貫して遅いか（キューなど）を調査できます。
実行グラフのログ
JSON トレース プロファイルにはクリティカル パス情報が含まれていますが、実行されたアクションの依存関係グラフに関する追加情報が必要になることがあります。Bazel 6.0 以降では、--experimental_execution_graph_log フラグと --experimental_execution_graph_log_dep_type=all フラグを渡して、実行されたアクションとそれらの相互依存関係に関するログを書き込むことができます。
この情報により、クリティカル パス上のノードによって追加されたドラッグを把握できます。ドラッグとは、実行グラフから特定のノードを削除することで節約できる時間です。
このデータにより、実際に変更を行う前に、ビルドグラフとアクション グラフを変更した場合の影響を予測できます。
bazel-bench によるベンチマーク
Bazel ベンチは、Git プロジェクトがベンチマーク ビルドを実施するためのベンチマーク ツールです。
プロジェクトのベンチマーク: 単一の Bazel バージョンで 2 つの git commit を相互にベンチマークします。ビルド内で回帰を検出するために使用されます（多くの場合、依存関係の追加を通じて）。
Bazel ベンチマーク: 単一の git commit で 2 つのバージョンの Bazel をベンチマークで比較する。Bazel 自体の回帰を検出するために使用します（Bazel のメンテナンスやフォークを行う場合）。
ベンチマークは、経過時間、CPU 時間とシステム時間、Bazel のヒープサイズをモニタリングします。
また、変動の原因を減らすために、他のプロセスを実行していない専用の物理マシンで Bazel ベンチを実行することをおすすめします。