問題タブ [microbenchmark]

JMHを使用して操作の複雑さを指定します。JMH を使ったことがなくても心配はいりません。JMH はestimateOperationメソッドを複数回起動し、平均時間を取得します。

質問: [narrow]このプログラムはMath.cbrt(Integer.MAX_VALUE)毎回計算しますか? それとも、一度計算して、後でキャッシュされた結果を返すだけですか?

質問: [広義]: JVM はメソッドの結果をキャッシュしますか?

HikariCP マイクロベンチマークを参考にしています。

よくわからない指標が 2 つありました。つまり、

• 接続サイクル オペレーション/ミリ秒
• ステートメント サイクル オペレーション/ミリ秒

上記のメトリック/測定値がデータベース接続のコンテキストで何を意味するのか、誰か説明してもらえますか?

ドキュメントによると、microbenchmark:::autoplot「ggplot2 を使用して、マイクロベンチマークのタイミングのより読みやすいグラフを生成します。」

涼しい！サンプルコードを試してみましょう:

ドキュメンテーションには...フワフワしたうねりについては何も表示されませんが、関数作成者によるこの回答からの私の最良の推測は、これは実行にかかった時間の平滑化された一連の箱ひげ図のようなものであり、上部と下部があるということです形状の本体に接続された四分位数。多分？これらのプロットは、ここで何が起こっているのかを知るにはあまりにも興味深いように見えます。

これは何のプロットですか？

こんにちは、さまざまな並べ替えアルゴリズムをマイクロベンチマークしようとしていますが、jmh とベンチマークのクイックソートで奇妙な問題が発生しました。私の実装に何か問題があるのか​​もしれません。誰かが問題がどこにあるのかを知るのを手伝ってくれたら、私は興味があります. まず、jdk 7 と jmh 0.9.1 で ubuntu 14.04 を使用します。ベンチマークを実行しようとする方法は次のとおりです。

他のアルゴリズムもありますが、多かれ少なかれ問題ないので省略しました。何らかの理由でクイックソートが非常に遅くなりました。時間の大きさが遅くなります！さらに、StackOverflowException なしで実行するには、より多くのスタック スペースを割り当てる必要があります。何らかの理由で、クイックソートは多くの再帰呼び出しを行っているようです。興味深いことに、メイン クラスでアルゴリズムを単純に実行すると、正常に実行されます (同じランダム分布と 100000 要素で)。スタックを増やす必要はなく、単純な nanotime ベンチマークは、他のアルゴリズムに非常に近い時間を示しています。また、JDK のベンチマークでは、jmh を使用してテストすると非常に高速であり、単純なナノタイム ベンチマークを使用した他のアルゴリズムに沿ってはるかに高速です。私はここで何か間違ったことをしていますか、それとも何かを見逃していますか? これが私のクイックソートアルゴリズムです：

これで、ピボットを選択したために、既に並べ替えられたデータに対してアルゴリズムを実行すると、アルゴリズムが非常に遅くなることがわかりました (O(n^2))。しかし、それでもランダム化されたもので実行し、メインメソッドでソートされたデータで実行しようとしても、ランダム化されたデータで jmh を使用したバージョンよりもはるかに高速でした。ここで何かが欠けていると確信しています。ここで他のアルゴリズムを含む完全なプロジェクトを見つけることができます: https://github.com/ignl/SortingAlgos/

ベンチマークにhttp://openjdk.java.net/projects/code-tools/jmh/を使用していますが、次のような結果が得られます。

「スコアエラー」列は正確には何を意味し、どのように解釈するのですか?

In a Java REST service performance test, I got an unexpected pattern: a method that creates and returns always the same value object in each invocation runs faster than another version that just returns the value object stored in a class or object field.

Code:

Byte code:

• Inline (faster): getstatic, invokestatic, invokevirtual, areturn
• Static filed (slower): getstatic, areturn
• Object field (slower): aload, getfield, areturn

Performance (using Apache AB, single thread, several runs with consistent results):

• Inline: 17078.29 [#/sec] (mean)
• Static field: 5242.64 [#/sec] (mean)
• Object field: 5417.40 [#/sec] (mean)

Environment: RHEL6 + JDK Oracle 1.7.0_60-b19 64bits

Is is possible that the JVM optimized the inline version with native code, but never considered optimizing the other two because they are already pretty small?