このページでは、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 build -c optとbazel cqueryを混在させる場合です。 各コマンドは、他のコマンドの分析キャッシュを破棄します。一般的に 特定のワークフローの期間中、固定のフラグのセットを使用しようとします。Bazel サーバーを失うと、分析キャッシュも失われます。Bazel サーバーには、 構成可能なアイドル その後シャットダウンされます。この時間は bazelrc ファイルを変更します。起動時にサーバーも再起動される フラグが変更されるため、これらのフラグは可能な限り変更しないでください。
注意: 押すと Bazel サーバーが強制終了されます。 Bazel の実行中に Ctrl+C を繰り返し押します。時間を節約したくなる その都度必要のない実行中のビルドを中断して Ctrl+C を 1 回押して、現在の呼び出しの正常な終了をリクエストします。
同じワークスペースから複数のフラグセットを使用する場合は、 複数の個別の出力ベースを使用し、
--output_baseで切り替える 設定されます。各出力ベースは独自の Bazel サーバーを取得します。
この条件を警告ではなくエラーにするには、
--noallow_analysis_cache_discard フラグ（Bazel 6.4.0 で導入）