Java HotSpotの作成者からのマイクロベンチマークの作成に関するヒント:
ルール0: JVMとマイクロベンチマークに関する評判の良い論文を読んでください。良いものはBrianGoetz、2005年です。マイクロベンチマークにあまり期待しないでください。限られた範囲のJVMパフォーマンス特性のみを測定します。
ルール1:タイミングフェーズの前にすべての初期化とコンパイルをトリガーするのに十分な、テストカーネルを最後まで実行するウォームアップフェーズを常に含めます。(ウォームアップフェーズでは、より少ない反復で問題ありません。経験則では、数万回の内部ループ反復です。)
ルール2:常にで実行-XX:+PrintCompilation
、-verbose:gc
あなたはコンパイラやJVMの他の部分は、あなたのタイミング位相中に予期しない仕事をしていないことを確認することができますので、など。
ルール2.1:タイミングフェーズとウォームアップフェーズの開始時と終了時にメッセージを出力するため、タイミングフェーズ中にルール2からの出力がないことを確認できます。
ルール3:-client
と-server
、およびOSRと通常のコンパイルの違いに注意してください。この-XX:+PrintCompilation
フラグは、非初期エントリポイントを示すアットマーク付きのOSRコンパイルを報告しますTrouble$1::run @ 2 (41 bytes)
。次に例を示します。最高のパフォーマンスが必要な場合は、クライアントよりもサーバーを優先し、OSRよりも通常のサーバーを優先します。
ルール4:初期化の影響に注意してください。印刷はクラスをロードして初期化するため、タイミングフェーズ中に初めて印刷しないでください。特にクラスのロードをテストする場合を除いて、ウォームアップフェーズ(または最終レポートフェーズ)以外で新しいクラスをロードしないでください(その場合、テストクラスのみをロードします)。ルール2は、そのような影響に対する最初の防衛線です。
ルール5:最適化解除と再コンパイルの影響に注意してください。パスがまったく使用されないという以前の楽観的な仮定に基づいて、コンパイラがコードをジャンクして再コンパイルする可能性があるため、タイミングフェーズで初めてコードパスを使用しないでください。ルール2は、そのような影響に対する最初の防衛線です。
ルール6:適切なツールを使用してコンパイラーの心を読み、コンパイラーが生成するコードに驚かされることを期待します。何かを速くしたり遅くしたりする理由について理論を立てる前に、自分でコードを調べてください。
ルール7:測定のノイズを減らします。静かなマシンでベンチマークを実行し、外れ値を破棄して数回実行します。-Xbatch
コンパイラをアプリケーションとシリアル化するために使用し、コンパイラ-XX:CICompilerCount=1
がそれ自体と並行して実行されないように設定することを検討してください。GCのオーバーヘッドを減らすために最善を尽くし、Xmx
(十分に大きい)等しい値Xms
を設定し、使用UseEpsilonGC
可能な場合はそれを使用します。
ルール8:ライブラリはおそらくより効率的であり、この唯一の目的のためにすでにデバッグされているため、ベンチマークにライブラリを使用します。などJMH、キャリパーやビルやJava用ポールの優れたUCSDベンチマーク。