TL;DR:你不应该盲目信任任何事情。
首先,重要的是先验证实验数据,然后再得出结论。仅仅声称某些东西快/慢 3 倍是很奇怪的,因为您确实需要跟进性能差异的原因,而不仅仅是相信数字。这对于像您这样的纳米基准测试尤其重要。
其次,实验者应该清楚地了解他们控制什么和不控制什么。在您的特定示例中,您返回的值来自@Benchmark
方法,但是您能否合理确定外部调用者会对原语和引用执行相同的操作?如果您问自己这个问题,您就会意识到您基本上是在测量测试基础设施。
切入正题。在我的机器(i5-4210U、Linux x86_64、JDK 8u40)上,测试结果:
Benchmark (value) Mode Samples Score Error Units
...benchmarkReturnOrdinal 3 thrpt 5 0.876 ± 0.023 ops/ns
...benchmarkReturnOrdinal 2 thrpt 5 0.876 ± 0.009 ops/ns
...benchmarkReturnOrdinal 1 thrpt 5 0.832 ± 0.048 ops/ns
...benchmarkReturnReference 3 thrpt 5 0.292 ± 0.006 ops/ns
...benchmarkReturnReference 2 thrpt 5 0.286 ± 0.024 ops/ns
...benchmarkReturnReference 1 thrpt 5 0.293 ± 0.008 ops/ns
好的,所以参考测试看起来慢了 3 倍。但是等等,它使用旧的 JMH (1.1.1),让我们更新到当前最新版本 (1.7.1):
Benchmark (value) Mode Cnt Score Error Units
...benchmarkReturnOrdinal 3 thrpt 5 0.326 ± 0.010 ops/ns
...benchmarkReturnOrdinal 2 thrpt 5 0.329 ± 0.004 ops/ns
...benchmarkReturnOrdinal 1 thrpt 5 0.329 ± 0.004 ops/ns
...benchmarkReturnReference 3 thrpt 5 0.288 ± 0.005 ops/ns
...benchmarkReturnReference 2 thrpt 5 0.288 ± 0.005 ops/ns
...benchmarkReturnReference 1 thrpt 5 0.288 ± 0.002 ops/ns
哎呀,现在他们只慢了一点点。顺便说一句,这也告诉我们测试是受基础设施限制的。好吧,我们能看看到底发生了什么吗?
如果你建立基准,并看看到底什么才是你的@Benchmark
方法,然后你会看到类似的内容:
public void benchmarkReturnOrdinal_thrpt_jmhStub(InfraControl control, RawResults result, ReturnEnumObjectVersusPrimitiveBenchmark_jmh l_returnenumobjectversusprimitivebenchmark0_0, Blackhole_jmh l_blackhole1_1) throws Throwable {
long operations = 0;
long realTime = 0;
result.startTime = System.nanoTime();
do {
l_blackhole1_1.consume(l_longname.benchmarkReturnOrdinal());
operations++;
} while(!control.isDone);
result.stopTime = System.nanoTime();
result.realTime = realTime;
result.measuredOps = operations;
}
That l_blackhole1_1
has a consume
方法,它“消耗”这些值(参见Blackhole
为理由)。Blackhole.consume
有过载参考 http://hg.openjdk.java.net/code-tools/jmh/file/96d8047fbf9a/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l298 and 原语 http://hg.openjdk.java.net/code-tools/jmh/file/96d8047fbf9a/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l384,仅此一点就足以证明性能差异是合理的。
这些方法看起来不同是有原因的:它们试图尽可能快地处理它们的论证类型。即使我们尝试匹配它们,它们也不一定表现出相同的性能特征,因此新 JMH 的结果更加对称。现在,您甚至可以前往-prof perfasm
查看为测试生成的代码并了解性能不同的原因,但这超出了这里的重点。
如果你真的want要了解返回原语和/或引用在性能方面有何不同,您需要输入大可怕的灰色地带细致入微的性能基准测试。例如。像这样的测试:
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(5)
public class PrimVsRef {
@Benchmark
public void prim() {
doPrim();
}
@Benchmark
public void ref() {
doRef();
}
@CompilerControl(CompilerControl.Mode.DONT_INLINE)
private int doPrim() {
return 42;
}
@CompilerControl(CompilerControl.Mode.DONT_INLINE)
private Object doRef() {
return this;
}
}
...这对于基元和引用产生相同的结果:
Benchmark Mode Cnt Score Error Units
PrimVsRef.prim avgt 25 2.637 ± 0.017 ns/op
PrimVsRef.ref avgt 25 2.634 ± 0.005 ns/op
正如我上面所说,这些测试require跟进结果的原因。在这种情况下,两者生成的代码几乎相同,这解释了结果。
prim:
[Verified Entry Point]
12.69% 1.81% 0x00007f5724aec100: mov %eax,-0x14000(%rsp)
0.90% 0.74% 0x00007f5724aec107: push %rbp
0.01% 0.01% 0x00007f5724aec108: sub $0x30,%rsp
12.23% 16.00% 0x00007f5724aec10c: mov $0x2a,%eax ; load "42"
0.95% 0.97% 0x00007f5724aec111: add $0x30,%rsp
0.02% 0x00007f5724aec115: pop %rbp
37.94% 54.70% 0x00007f5724aec116: test %eax,0x10d1aee4(%rip)
0.04% 0.02% 0x00007f5724aec11c: retq
ref:
[Verified Entry Point]
13.52% 1.45% 0x00007f1887e66700: mov %eax,-0x14000(%rsp)
0.60% 0.37% 0x00007f1887e66707: push %rbp
0.02% 0x00007f1887e66708: sub $0x30,%rsp
13.63% 16.91% 0x00007f1887e6670c: mov %rsi,%rax ; load "this"
0.50% 0.49% 0x00007f1887e6670f: add $0x30,%rsp
0.01% 0x00007f1887e66713: pop %rbp
39.18% 57.65% 0x00007f1887e66714: test %eax,0xe3e78e6(%rip)
0.02% 0x00007f1887e6671a: retq
[讽刺]看看这有多容易! [/讽刺]
模式是:问题越简单,你就越需要做出更多的努力才能得出合理且可靠的答案。