如何在Java中编写正确的微基准测试？

你如何在Java中编写(并运行)正确的微基准测试？

我在这里寻找代码示例和注释,说明要考虑的各种事项.

示例:基准测量应该测量时间/迭代或迭代/时间,为什么？

相关:秒表基准可以接受吗？

1> 小智..：

---

关于从Java HotSpot的创建者编写微基准的提示:

规则0:阅读有关JVM和微基准测试的着名论文.一个好的是Brian Goetz,2005.微观基准不要期望太多; 它们仅测量有限范围的JVM性能特征.

规则1:始终包括一个运行测试内核的预热阶段,足以在计时阶段之前触发所有初始化和编译.(在预热阶段,迭代次数较少.经验法则是数万次内循环迭代.)

规则2:始终使用-XX:+PrintCompilation,-verbose:gc等等,以便您可以验证编译器和JVM的其他部分在计时阶段没有执行意外工作.

规则2.1:在计时和预热阶段的开始和结束时打印消息,这样您就可以在计时阶段验证规则2中没有输出.

规则3:注意-client和-server,OSR和常规编译之间的区别.该-client标志报告带有at符号的OSR编译,以表示非初始入口点,例如:-server.如果您追求最佳性能,则首选服务器到客户端,并定期访问OSR.

规则4:注意初始化效果.在打印加载和初始化类时,不要在计时阶段第一次打印.除非您专门测试类加载(并且在这种情况下仅加载测试类),否则不要在预热阶段(或最终报告阶段)之外加载新类.规则2是您抵御此类影响的第一道防线.

规则5:注意去优化和重新编译效果.不要在计时阶段第一次采用任何代码路径,因为编译器可能会破坏并重新编译代码,这是基于先前的乐观假设,即路径根本不会被使用.规则2是您抵御此类影响的第一道防线.

规则6:使用适当的工具来阅读编译器的思想,并期望对它产生的代码感到惊讶.在形成关于什么使得更快或更慢的东西的理论之前,自己检查代码.

规则7:减少测量中的噪音.在安静的机器上运行您的基准测试,并运行几次,丢弃异常值.用于使用-XX:+PrintCompilation应用程序序列化编译器,并考虑设置Trouble$1::run @ 2 (41 bytes)以防止编译器与其自身并行运行.尽量减少GC开销,设置-Xbatch(足够大)等于-XX:CICompilerCount=1并使用(Xmx如果可用).

规则8:使用库作为您的基准测试,因为它可能更有效,并且已经针对此唯一目的进行了调试.例如JMH,Caliper或Bill和Paul的优秀UCSD Java基准.

---

此外,永远不要使用System.currentTimeMillis(),除非您的准确度为+或 - 15毫秒,这在大多数OS + JVM组合中是典型的.请改用System.nanoTime().

---

应该注意的是,`System.nanoTime()`不是_guaranteed_比`System.currentTimeMillis()`更准确.它只能保证至少同样准确.然而,它通常更准确.

---

必须使用`System.nanoTime()`而不是`System.currentTimeMillis()`的主要原因是前者保证单调递增.减去返回的两个`currentTimeMillis`调用实际上可以给出否定结果,可能是因为系统时间是由某个NTP守护进程调整的.

---

这也是一篇有趣的文章:http://www.ibm.com/developerworks/java/library/j-jtp12214/

---

来自javaOne的一些论文:http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf

2> Aravind R. Y..：

---

我知道这个问题已被标记为已回答,但我想提及两个使我们能够编写微基准的库

来自Google的Caliper

入门教程

http://codingjunkie.net/micro-benchmarking-with-caliper/

http://vertexlabs.co.uk/blog/caliper

来自OpenJDK的JMH

入门教程

避免JVM上的基准测试陷阱

http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking

http://java-performance.info/jmh/

---

+1它可以作为已接受答案的规则8添加:规则8:因为很多事情都可能出错,你应该使用现有的库而不是自己动手做!

---

@Pangea jmh现在可能优于Caliper,参见:https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ

3> Jon Skeet..：

---

Java基准测试的重要事项是:

首先通过运行代码多次预热JIT,然后再计时

确保运行它足够长的时间,以便能够在几秒或更好(几十秒)内测量结果

虽然你不能System.gc()在迭代之间调用,但在测试之间运行它是个好主意,这样每个测试都有望获得一个"干净"的内存空间.(是的,gc()更多的是暗示而不是保证,但很可能在我的经验中真的会收集垃圾.)

我喜欢显示迭代和时间,以及可以缩放的时间/迭代分数,使得"最佳"算法得分为1.0而其他算法以相对方式得分.这意味着您可以长时间运行所有算法,同时改变迭代次数和时间,但仍然可以获得可比较的结果.

我正在撰写关于.NET中基准测试框架设计的博客.我有一对夫妇的较早的帖子这或许可以给你一些想法-而不是一切都将是合适的,当然,但它的一些可能.

---

@gyabraham:是的,这是一个暗示 - 但它是我经常观察到的一个.因此,如果你不喜欢使用`System.gc()`,你如何建议在一次测试中最小化垃圾收集,因为在之前的测试中创建了对象？我很务实,不是教条主义.

---

@gyabraham:我不知道"伟大的后备"是什么意思.你能详细说明一下 - 你有建议给出更好的结果吗？我明确地说这不是保证......

---

轻微的挑剔:IMO"以便每个测试得到"应该"以便每个测试可能得到"因为前者给人的印象是调用`gc`*总是*释放未使用的内存.

4> assylias..：

---

jmh是OpenJDK的最新成员,由Oracle的一些性能工程师编写.当然值得一看.

jmh是一个Java工具,用于构建,运行和分析用Java和其他针对JVM的语言编写的nano/micro/macro基准测试.

非常有趣的信息隐藏在样本测试评论中.

也可以看看:

避免JVM上的基准测试陷阱

讨论jmh的主要优势.

5> Peter Lawrey..：

---

基准测量应该测量时间/迭代或迭代/时间,为什么？

这取决于你要测试的内容.如果您对延迟感兴趣,请使用时间/迭代,如果您对吞吐量使用迭代/时间感兴趣.

6> Kip..：

---

如果您要比较两个算法,请在每个算法上至少执行两个基准测试,以交替顺序.即:

for(i=1..n)
  alg1();
for(i=1..n)
  alg2();
for(i=1..n)
  alg2();
for(i=1..n)
  alg1();

我在不同的传递中在相同算法的运行时中发现了一些明显的差异(有时为5-10%).

另外,请确保n非常大,以便每个循环的运行时间至少为10秒左右.迭代次数越多,基准时间内的数字越重要,数据越可靠.

---

自然地改变顺序会影响运行时.JVM优化和缓存效果将在这里起作用.更好的是"预热"JVM优化,进行多次运行并在不同的JVM中对每个测试进行基准测试.

7> Peter Štibra..：

---

确保以某种方式使用在基准代码中计算的结果.否则,您的代码可以被优化掉.

8> Mnementh..：

---

在Java中编写微基准测试有许多可能的缺陷.

第一:你必须用各种各样的事件来计算,这些事件或多或少是随机的:垃圾收集,缓存效果(文件操作系统和内存CPU),IO等.

第二:在非常短的时间间隔内,您不能相信测量时间的准确性.

第三:JVM在执行时优化代码.因此,同一JVM实例中的不同运行将变得越来越快.

我的建议:让您的基准测试运行几秒钟,这比运行时间超过几毫秒更可靠.预热JVM(意味着至少运行基准测试一次而不进行测量,JVM可以运行优化).并多次运行您的基准测试(可能是5次)并取中值.在新的JVM实例中运行每个微基准测试(调用每个基准测试新Java),否则JVM的优化效果会影响以后运行的测试.不要执行在预热阶段没有执行的事情(因为这可能会触发类加载和重新编译).

9> SpaceTrucker..：

---

还应该注意,在比较不同的实现时,分析微基准的结果可能也很重要.因此,应进行重要性测试.

这是因为A在基准测试的大多数运行期间实现可能比实现更快B.但A也可能有更高的传播,因此A与之相比,测量的性能优势不会有任何意义B.

因此,正确编写和运行微基准测试也很重要,同时也要正确分析它.

10> 小智..：

---

http://opt.sourceforge.net/ Java Micro Benchmark - 控制在不同平台上确定计算机系统的比较性能特征所需的任务.可用于指导优化决策和比较不同的Java实现.

---

似乎只是对JVM +硬件进行基准测试，而不是任意Java代码。

11> Sina Madani..：

---

为了增加其他优秀的建议,我还要注意以下几点:

对于某些CPU(例如带有TurboBoost的Intel Core i5系列),温度(以及当前使用的内核数量以及更高的利用率百分比)会影响时钟速度.由于CPU是动态计时的,因此会影响您的结果.例如,如果您有单线程应用程序,则最大时钟速度(使用TurboBoost)高于使用所有核心的应用程序.因此,这可能会干扰某些系统上单线程和多线程性能的比较.请记住,温度和波动也会影响Turbo频率的维持时间.

也许您可以直接控制一个更为根本的重要方面:确保您正确测量!例如,如果您正在使用System.nanoTime()特定位代码的基准测试,请将调用的调用放在有意义的位置,以避免测量您不感兴趣的内容.例如,不要这样做:

long startTime = System.nanoTime();
//code here...
System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");

问题是你没有立即得到代码完成时的结束时间.相反,请尝试以下方法:

final long endTime, startTime = System.nanoTime();
//code here...
endTime = System.nanoTime();
System.out.println("Code took "+(endTime-startTime)+"nano seconds");