このページでは、Bazel を繰り返し実行するときに Bazel のビルド パフォーマンスを最適化する方法について説明します。
Bazel のランタイム状態
Bazel の呼び出しには、相互作用する複数の部分が関与します。
bazelコマンドライン インターフェース（CLI）は、ユーザー向けのフロントエンド ツールであり、ユーザーからコマンドを受け取ります。CLI ツールは、個別の出力ベースごとに Bazel サーバーを起動します。Bazel サーバーは通常は永続的ですが、リソースを浪費しないように、アイドル状態が続くとシャットダウンします。
Bazel サーバーは、特定のコマンド（
build、run、cqueryなど）の読み込みと分析ステップを実行します。このとき、ビルドグラフの必要な部分がメモリ内に構築されます。生成されたデータ構造は、分析キャッシュの一部として Bazel サーバーに保持されます。Bazel サーバーは、アクション実行を実行することも、リモート実行用にアクションを送信することもできます（設定されている場合）。アクション実行の結果もキャッシュに保存されます。つまり、アクション実行の結果はアクション キャッシュ（またはローカルまたはリモートの実行キャッシュ。ローカルかリモートのどちらかで、Bazel サーバー間で共有される場合があります）にキャッシュされます。
Bazel 呼び出しの結果は出力ツリーで確認できます。
Bazel を反復的に実行する
一般的なデベロッパー ワークフローで、コードを繰り返しビルド（または実行）することはよくあります（コンパイル エラーを解決したり、失敗したテストを調査したりする場合など）。この場合、bazel の繰り返し呼び出しのオーバーヘッドは、基盤となる繰り返しアクション（コンパイラの呼び出しやテストの実行など）に比べて可能な限り少なくすることが重要です。
これを念頭に置いて、Bazel のランタイム状態をもう一度見てみましょう。
分析キャッシュはデータの重要な要素です。コールド実行（Bazel サーバーの起動直後や分析キャッシュが破棄されたときの実行）の読み込みフェーズと分析フェーズだけで、かなりの時間が費やされる可能性があります。単一の成功したコールドビルド（製品版リリースなど）の場合、このコストは許容範囲内ですが、同じターゲットを繰り返しビルドするには、このコストを平均化し、呼び出しのたびに繰り返さないことが重要です。
分析キャッシュは比較的不安定です。まず、これは Bazel サーバーの処理中状態の一部であるため、サーバーが失われるとキャッシュも失われます。ただし、キャッシュは非常に簡単に無効になります。たとえば、多くの bazel コマンドライン フラグによってキャッシュが破棄されます。これは、多くのフラグがビルドグラフに影響するためです（構成可能な属性など）。フラグの変更によっては、Bazel サーバーが再起動されることもあります（起動オプションの変更など）。
優れた実行キャッシュは、ビルドのパフォーマンスにも役立ちます。実行キャッシュは、ローカルのディスクまたはリモートに保存できます。キャッシュは Bazel サーバー間で、またデベロッパー間で共有できます。
分析キャッシュを破棄しないようにする
分析キャッシュが破棄されたか、サーバーが再起動された場合、Bazel は警告を出力します。反復使用中は、次のいずれかを行うことは避けてください。
反復的なワークフローの途中で
bazelフラグを変更する際は注意してください。たとえば、bazel build -c optとbazel cqueryを混在させると、各コマンドで他方の分析キャッシュが破棄されます。一般に、特定のワークフローの期間中は、固定されたフラグのセットを使用することをおすすめします。Bazel サーバーを失うと、分析キャッシュも失われます。Bazel サーバーは、構成可能なアイドル時間を経過するとシャットダウンします。この時間は、bazelrc ファイルでニーズに合わせて構成できます。起動フラグが変更されるとサーバーも再起動されるため、可能であればこれらのフラグの変更は避けてください。
Bazel の実行中に Ctrl-C を繰り返し押すと、Bazel サーバーが強制終了します。注意してください。実行中のビルドが不要になった場合は中断して時間を節約したくなるかもしれませんが、Ctrl+C を 1 回だけ押して現在の呼び出しの正常終了をリクエストします。
同じワークスペースから複数のフラグセットを使用する場合は、
--output_baseフラグで切り替えて、複数の異なる出力ベースを使用できます。各出力ベースは独自の Bazel サーバーを取得します。