如何用Java编写正确的微基准?


870

您如何用Java编写(并运行)正确的微基准测试?

我正在寻找一些代码示例和注释,以说明要考虑的各种问题。

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

相关:秒表基准测试是否可以接受?


请参阅几分钟前的[this question] [1],以获取一些相关信息。编辑:对不起,这不应该是一个答案。我应该发表评论。[1]:stackoverflow.com/questions/503877/…–
Tiago

在计划将这个问题的发布者转介给这样一个问题之后,我注意到这个问题不存在。就是这样,希望它会随着时间的流逝收集一些好的技巧。
John Nilsson

5
Java 9可能提供了一些微基准测试功能:openjdk.java.net/jeps/230
Raedwald,

1
@Raedwald我认为JEP旨在向JDK代码添加一些微型基准,但是我不认为jmh将包含在JDK中……
assylias 2015年

1
@Raedwald未来的您好。它没有晋级
迈克尔·迈克尔(Michael

Answers:


787

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

规则0:阅读有关JVM和微基准测试的著名论文。好的人是布莱恩·格茨Brian Goetz),2005年。不要对微观基准期望太高;它们仅测量有限范围的JVM性能特征。

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

规则2:始终与-XX:+PrintCompilation-verbose:gc等一起运行,因此您可以验证在计时阶段,编译器和JVM的其他部分是否未进行意外工作。

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

规则3:请注意-client-server,OSR和常规编译之间的区别。该-XX:+PrintCompilation标志报告OSR编译时带有一个符号,以表示非初始入口点,例如:Trouble$1::run @ 2 (41 bytes)。如果您追求最佳性能,则优先选择服务器而不是客户端,并经常选择OSR。

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

规则5:注意优化和重新编译的影响。在时序阶段不要第一次采用任何代码路径,因为基于较早的乐观假设,即根本不会使用该路径,编译器可能会垃圾并重新编译代码。规则2是抵御此类影响的第一道防线。

规则6:使用适当的工具来阅读编译器的思想,并期望对其生成的代码感到惊讶。在形成有关使事物变快或变慢的理论之前,请自己检查代码。

规则7:减少测量中的噪音。在安静的计算机上运行基准测试,然后运行几次,丢弃异常值。用于-Xbatch将编译器与应用程序序列化,并考虑进行设置-XX:CICompilerCount=1以防止编译器与其自身并行运行。尽最大努力减少GC开销,将其设置Xmx(足够大)等于Xms并使用(UseEpsilonGC如果可用)。

规则8:将库用于您的基准测试,因为它可能更有效,并且已经为此目的进行了调试。例如JMHCaliperBill和Paul的Java优秀UCSD基准



142
另外,除非您可以使用+或-15 ms的精度,否则不要使用System.currentTimeMillis(),这在大多数OS + JVM组合中都很常见。使用System.nanoTime()代替。
Scott Carey


93
应该注意的System.nanoTime()是,不能保证比更加准确System.currentTimeMillis()。它只能保证至少是准确的。但是,它通常会更加准确。
重力

41
必须使用System.nanoTime()代替的主要原因System.currentTimeMillis()是保证前者单调增加。将两次currentTimeMillis调用减去返回的值实际上可以得到否定的结果,这可能是因为系统时间是由某些NTP守护程序调整的。
Waldheinz

239

37
+1可能已被添加为公认答案的规则8:规则8:由于很多事情可能出错,因此您应该使用现有的库,而不要自己动手做!
assylias 2012年

8
@Pangea jmh现在可能优于Caliper,另请参见:groups.google.com/forum
#!msg/mechanical

86

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

  • 先热身JIT通过运行代码几次定时之前
  • 确保运行足够长的时间,以便能够在几秒钟或更好的几十秒内测量结果
  • 虽然您不能System.gc()在迭代之间调用,但是在测试之间运行它是一个好主意,这样每个测试都有望获得一个“干净的”内存空间来使用。(是的,gc()更多的是提示而不是保证,但是根据我的经验,它很有可能真的会造成垃圾回收。)
  • 我喜欢显示迭代次数和时间,以及可以缩放的时间/迭代得分,以使“最佳”算法获得1.0得分,而其他算法则以相对方式得分。这意味着您可以长时间运行所有算法,同时改变迭代次数和时间,但仍可获得可比的结果。

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


3
次要问题:IMO“使每个测试通过”应为“使每个测试可以通过”,因为前者给人的印象是调用gc 总是释放未使用的内存。
Sanjay T. Sharma

@ SanjayT.Sharma:好吧,目的是要这样做。尽管没有严格保证,但这实际上是一个很强的暗示。将进行编辑以使其更清晰。
乔恩·斯基特

1
我不同意调用System.gc()。提示,仅此而已。甚至没有“它有望完成某件事”。您永远都不要称呼它。这是编程,而不是艺术。
gyorgyabraham 2013年

13
@gyabraham:是的,这是一个提示-但是,我观察到这通常是一个提示。因此,如果您不喜欢使用System.gc(),由于先前测试中创建的对象,您如何建议在一个测试中最大程度地减少垃圾收集?我很务实,不是教条。
乔恩·斯基特

9
@gyabraham:我不知道您所说的“大后备”。您能否再详细说明-您是否有建议可以提供更好的结果?我确实明确地说过,这不是保证...
Jon Skeet

48

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

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

样本测试注释中隐藏了非常有趣的信息。

也可以看看:


1
另请参阅此博客文章:psy-lob-saw.blogspot.com/2013/04/…,以获取有关JMH入门的详细信息。
Nitsan Wakart


23

基准测试应该测量时间/迭代次数还是迭代/时间,为什么?

这要看是什么你想测试。

如果您对延迟感兴趣,请使用时间/迭代,如果您对吞吐量感兴趣,请使用迭代/时间。


16

如果要比较两种算法,请为每种算法至少执行两个基准测试,以交替顺序。即:

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

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

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


5
自然地更改顺序会影响运行时间。JVM优化和缓存效果将在这里起作用。更好的办法是“热身” JVM优化,进行多次运行,并在不同的JVM中对每个测试进行基准测试。
Mnementh,2009年


13

用Java编写微基准有很多可能的陷阱。

首先:您必须计算各种事件,这些事件或多或少地需要时间,这些事件包括:垃圾回收,缓存效果(文件用于OS,内存用于CPU),IO等。

第二:您不能相信很短的时间间隔内测量时间的准确性。

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

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


8

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

这是因为A在基准测试的大多数运行过程中,实施可能比实施要快B。但是A可能还会有更高的价差,因此与相比,衡量的性能优势A将没有任何意义B

因此,正确编写和运行微基准测试以及正确分析它也很重要。


8

除了其他出色的建议,我还请注意以下几点:

对于某些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");

是的,不要在定时区域内进行无关的工作很重要,但是您的第一个示例仍然可以。这里只有一个调用println,而不是一个单独的标题行什么的,System.nanoTime()已被评为第一个在构造字符串ARG该呼叫一步。编译器无法对第一个执行任何操作,而对第二个则无法执行,而且甚至没有人鼓励他们在记录停止时间之前做额外的工作。
彼得·科德斯

7

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


2
似乎只是对JVM +硬件进行了基准测试,而不是任意的Java代码。
Stefan L
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.