受another question on Stack Overflow的启发,我写了一个微基准来检查,效率更高:
ArithmeticException
以下是我的代码:
@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {
private int a = 10;
// a little bit less obvious than int b = 0;
private int b = (int) Math.floor(Math.random());
@Benchmark
public float conditional() {
if (b == 0) {
return 0;
} else {
return a / b;
}
}
@Benchmark
public float exceptional() {
try {
return a / b;
} catch (ArithmeticException aex) {
return 0;
}
}
}
我对JMH完全不熟悉,也不确定代码是否合适。
我的基准是否正确?你看到有什么错误吗?
方面不是:请不要建议https://codereview.stackexchange.com询问。对于Codereview代码必须已按预期工作。我不确定这个基准程序是否按预期工作。
答案 0 :(得分:2)
我看到的重要事情是任何形式的随机性。这将使分支预测更容易完成其工作,这将使两种方法比实际划分为0时更快。
我会对每种方法做三种变化:
这应该可以让您对整体性能有所了解,包括分支预测。对于点(1),使用0到非0的比率也可能是有趣的。
我忘记了JMH是否允许您直接参数化数组的各个值。如果确实如此,那我就用它。否则,您必须对该数组的索引进行参数化。在这种情况下,我还将all-0放在一个数组中,以便逗留访问是所有测试的一部分。我也可能会创建一个"控件"只访问数组并返回其值,以便您可以更直接地找到该开销。
此外,还有一个小问题:我不认为你需要返回花车,因为它们只是从分组实际产生的整数转换而来。