jmh

JMH是有OpenJDK开发的基准测试（Benchmark）工具。JMH可以为写基准测试和运行测试提供很好的支持。JMH在C oncurrent Benchmarks也提供很好的支持，可以说是多功能测试工具。JMH在2013被公布出来，现在最新版本到1.9。 JMH基本用法: JMH环境构建 1 使用maven工程，直接在项目中引入相应的jar包 <dependency> <groupId>org.openjdk.jmh</groupId> <artifactId>jmh-core</artifactId> <version>${jmh.version}</version> </dependency> <dependency> <groupId>org.openjdk.jmh</groupId> <artifactId>jmh-generator-annprocess</artifactId> <version>${jmh.version}</version> <scope>provided</scope> </dependency> 2 或者直接用JMH的 archetype创建： mvn archetype:generate \ -DinteractiveMode=false \ -DarchetypeGroupId=org.openjdk.jmh \

The JavaDoc of annotation @OperationsPerInvocation in the Java Microbenchmarking Harness (JMH) states: value public abstract int value Returns: Number of operations per single Benchmark call. Default: 1 Being new to JMH I am wondering what type of operation (byte code operation, assembly code operation, Java operation etc) is meant here. This question naturally refers to all places in JMH (documentation, output, comments etc) where the term 'operation' is used (e.g. " operation/time " unit or "time unit/operation "). In JMH, "operation" is an abstract unit of work. See e.g. the sample result:

My ultimate goal is to create a comprehensive set of benchmarks for several Java primitive collection libraries using the standard Java collections as a baseline. In the past I have used the looping method of writing these kinds of micro-benchmarks. I put the function I am benchmarking in a loop and iterate 1 million+ times so the jit has a chance to warmup. I take the total time of the loop and then divide by the number of iterations to get an estimate for the amount of time a single call to the function I am benchmarking would take. After recently reading about the JMH project and

I'm comparing performance of MethodHandle::invoke and direct static method invokation. Here is the static method: public class IntSum { public static int sum(int a, int b){ return a + b; } } And here is my benchmark: @State(Scope.Benchmark) public class MyBenchmark { public int first; public int second; public final MethodHandle mhh; @Benchmark @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(Mode.AverageTime) public int directMethodCall() { return IntSum.sum(first, second); } @Benchmark @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(Mode.AverageTime) public int finalMethodHandle()

Since the beginning of CPUs it has been general knowledge that the integer division instruction is expensive. I went to see how bad it is today, on CPUs which have the luxury of billions of transistors. I found that the hardware idiv instruction still performs significantly worse for constant divisors than the code the JIT compiler is able to emit, which doesn't contain the idiv instruction. To bring this out in a dedicated microbenchmark I've written the following: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @OperationsPerInvocation(MeasureDiv.ARRAY_SIZE) @Warmup