您如何在 Java 中编写(和运行)正确的微基准测试?
我正在寻找一些代码示例和注释来说明要考虑的各种事情。
示例:基准测试应该测量时间/迭代还是迭代/时间,为什么?
相关:Is stopwatch benchmarking acceptable?
关于编写微基准测试的提示from the creators of Java HotSpot:
规则 0: 阅读有关 JVM 和微基准测试的著名论文。一个好的是Brian Goetz, 2005。不要对微基准有太多期望;它们仅测量有限范围的 JVM 性能特征。
规则 1:始终包含一个预热阶段,它会一直运行您的测试内核,足以在计时阶段之前触发所有初始化和编译。 (在预热阶段,较少的迭代是可以的。经验法则是数万次内循环迭代。)
规则 2: 始终与 -XX:+PrintCompilation
、-verbose:gc
等一起运行,这样您就可以验证编译器和 JVM 的其他部分在您的计时阶段没有做意外的工作。
规则 2.1:在计时和预热阶段的开始和结束时打印消息,以便您可以验证在计时阶段没有来自规则 2 的输出。
规则 3:注意 -client
和 -server
以及 OSR 和常规编译之间的区别。 -XX:+PrintCompilation
标志使用 at 符号报告 OSR 编译以表示非初始入口点,例如:Trouble$1::run @ 2 (41 bytes)
。如果您追求最佳性能,则首选服务器而不是客户端,并且经常使用 OSR。
规则 4:注意初始化效果。不要在计时阶段第一次打印,因为打印会加载并初始化类。不要在预热阶段(或最终报告阶段)之外加载新类,除非您正在专门测试类加载(并且在这种情况下仅加载测试类)。规则 2 是您抵御此类影响的第一道防线。
规则 5:注意反优化和重新编译的影响。在计时阶段第一次不要采用任何代码路径,因为编译器可能会根据先前的乐观假设,即根本不会使用该路径,从而产生垃圾并重新编译代码。规则 2 是您抵御此类影响的第一道防线。
规则 6:使用适当的工具来读懂编译器的想法,并期望对它产生的代码感到惊讶。在形成关于什么使某事变得更快或更慢的理论之前,自己检查代码。
规则 7: 减少测量中的噪音。在安静的机器上运行你的基准测试,并运行几次,丢弃异常值。使用 -Xbatch
将编译器与应用程序一起序列化,并考虑设置 -XX:CICompilerCount=1
以防止编译器与自身并行运行。尽量减少 GC 开销,设置 Xmx
(足够大)等于 Xms
并使用 UseEpsilonGC
(如果可用)。
规则 8: 使用库作为基准,因为它可能更有效,并且已经为此目的进行了调试。例如 JMH、Caliper 或 Bill and Paul's Excellent UCSD Benchmarks for Java。
我知道这个问题已被标记为已回答,但我想提两个帮助我们编写微基准测试的库
入门教程
http://codingjunkie.net/micro-benchmarking-with-caliper/ http://vertexlabs.co.uk/blog/caliper
入门教程
避免 JVM 上的基准测试陷阱 使用 JMH 进行 Java 微基准测试 JMH 简介
Java 基准测试的重要事项是:
首先通过多次运行代码来预热 JIT,然后再对其计时
确保你运行它足够长的时间,以便能够在几秒或(更好)几十秒内测量结果
虽然您不能在迭代之间调用 System.gc(),但在测试之间运行它是一个好主意,这样每个测试都有望获得一个“干净的”内存空间来使用。 (是的,gc() 更像是一个提示而不是保证,但根据我的经验,它很可能真的会垃圾收集。)
我喜欢显示迭代和时间,以及可以缩放的时间/迭代分数,以便“最佳”算法获得 1.0 分,而其他算法则以相对方式得分。这意味着您可以长时间运行所有算法,改变迭代次数和时间,但仍能获得可比较的结果。
我正在撰写有关 .NET 基准测试框架设计的博客。我有一个 earlier posts 的 couple,它可能会给你一些想法 - 当然,并不是所有的东西都是合适的,但其中一些可能是合适的。
gc
总是 会释放未使用的内存。
System.gc()
,您如何建议在一个测试中尽量减少由于先前测试中创建的对象而导致的垃圾收集?我是务实的,不是教条的。
jmh 是 OpenJDK 的最新新增功能,由 Oracle 的一些性能工程师编写。当然值得一看。
jmh 是一个 Java 工具,用于构建、运行和分析用 Java 和其他针对 JVM 的语言编写的纳米/微型/宏观基准。
隐藏在 the sample tests comments 中的非常有趣的信息。
也可以看看:
避免 JVM 上的基准测试陷阱
关于jmh的主要优势的讨论。
基准测试应该测量时间/迭代还是迭代/时间,为什么?
这取决于您要测试的内容。
如果您对延迟感兴趣,请使用时间/迭代;如果您对吞吐量感兴趣,请使用迭代/时间。
确保您以某种方式使用在基准代码中计算的结果。否则你的代码可以被优化掉。
如果您尝试比较两种算法,请为每种算法至少做两个基准测试,交替顺序。 IE:
for(i=1..n)
alg1();
for(i=1..n)
alg2();
for(i=1..n)
alg2();
for(i=1..n)
alg1();
我在不同通道中同一算法的运行时发现了一些明显的差异(有时 5-10%)。
此外,请确保 n 非常大,以便每个循环的运行时间至少为 10 秒左右。迭代次数越多,基准时间中的重要数字就越多,数据就越可靠。
在 Java 中编写微基准测试有许多可能的陷阱。
首先:您必须计算各种花费时间或多或少随机的事件:垃圾收集、缓存效果(文件的 OS 和 CPU 的内存)、IO 等。
第二:您不能相信在很短的时间间隔内测量的时间的准确性。
第三:JVM 在执行时优化你的代码。因此,在同一个 JVM 实例中的不同运行将变得越来越快。
我的建议:让你的基准测试运行几秒钟,这比运行几毫秒更可靠。预热 JVM(意味着至少运行一次基准测试而不进行测量,JVM 可以运行优化)。并多次运行您的基准测试(可能 5 次)并取中值。在新的 JVM 实例中运行每个微基准测试(调用每个新 Java 基准测试),否则 JVM 的优化效果会影响以后运行的测试。不要执行在预热阶段未执行的事情(因为这可能会触发类加载和重新编译)。
还应该注意的是,在比较不同的实现时,分析微基准测试的结果可能也很重要。因此应该创建一个significance test。
这是因为在大多数基准测试运行期间,实施 A
可能比实施 B
更快。但 A
也可能具有更高的分布,因此与 B
相比,A
的衡量性能优势不会有任何意义。
因此,正确编写和运行微基准测试也很重要,而且要正确分析它。
为了补充其他出色的建议,我还要注意以下几点:
对于某些 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 的 first 步骤进行评估。编译器对第一个没有什么是他们不能对第二个做的,甚至没有人鼓励他们在记录停止时间之前做额外的工作。
http://opt.sourceforge.net/ Java Micro Benchmark - 确定计算机系统在不同平台上的比较性能特征所需的控制任务。可用于指导优化决策和比较不同的 Java 实现。
System.nanoTime()
并不保证比System.currentTimeMillis()
更准确。它只能保证至少一样准确。然而,它通常更准确。System.nanoTime()
而不是System.currentTimeMillis()
的主要原因是前者保证单调递增。减去两次currentTimeMillis
调用返回的值实际上会产生负面结果,可能是因为系统时间已被某些 NTP 守护程序调整。