【翻訳】Javaでベンチマークテストを書いた経験

時々、単純なパフォーマンス テスト コードを作成する必要があるのですが、環境の影響を可能な限り防ぐためのベンチマーク テストの作成方法について、スタックオーバーフローに関する経験談をたまたま目にしました。

ここに翻訳して投稿しました:

Java HotSpot の作者からのマイクロベンチマーク作成のヒント:

ルール 0: JVM とマイクロベンチマークに関する優れた論文を読んでください。例えば。このようなテストでは、JVM パフォーマンスの限られた尺度しか提供されないため、過度な期待はしないでください。

ルール 1: すべての初期化とコンパイルがトリガーされるまで実行されるウォームアップ フェーズを常に含めます。 (ウォームアップ段階の反復回数は減らすことができます。経験則では数万ループです。)

ルール 2: 常に -XX:+PrintCompilation、-verbose:gc などのパラメーターを使用して実行します。 . コンパイル フェーズや JVM のその他の側面を決定します。セクションはタイミングを計る際に予期しない動作を行いますか。

ルール 2.1: タイミングおよびウォームアップ フェーズの開始時と終了時にメッセージを出力します。これにより、タイミング中にルール 2 からの出力があるかどうかを判断できます。

ルール 3: -client と -server の違い、および OSR と通常のアセンブリの違いを理解します。 -server は -client よりも優れており、通常のコンパイルは OSR よりも優れています

ルール 4: 初期化の影響に注意し、テスト クラスのロード プロセス中でない限り、初めて結果を出力しないでください。ルール 2 は次のとおりです。この効果的な防御線に対抗するための最初の方法です。

ルール 5: コンパイラーの最適化と再コンパイルの影響に注意してください。コンパイラはパスがまったく使用されず、コードが破棄されて再コンパイルされる可能性があるなど、いくつかの楽観的な仮定に基づいて最適化される可能性があるため、タイミングを計るときにコード パスを使用しないでください。ルール 2 は、この効果に対する最初の防御線です。

ルール 6: 適切なツールを使用してコンパイラーの動作を読み取り、そこから素晴らしいコードをうまく生成します。何が物事を速くするか遅くするかについて理論を立てる前に、自分でコードを確認してください。

ルール 7: 測定時のノイズを低減します。静かなマシンでベンチマークを実行し、異常値を破棄しながら数回実行します。 -Xbatch を使用してアプリケーションでコンパイラをシリアル化し、コンパイラがそれ自体と並行して実行されないように -XX:CICompilerCount=1 を設定することを検討してください。

ルール 8: ベンチマークには、より効率的な可能性があるため、ライブラリを使用します。 JMH、Caliper、Java 用 UCSD ベンチマークなど。

以上が【翻訳】Javaでベンチマークテストを書いた経験の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。