943

您如何在 Java 中编写（和运行）正确的微基准测试？

我正在寻找一些代码示例和注释来说明要考虑的各种事情。

示例：基准测试应该测量时间/迭代还是迭代/时间，为什么？

相关：秒表基准测试是否可以接受？

4

11 回答 11

842

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（足够大）equalsXms并UseEpsilonGC在可用时使用。

规则 8：为您的基准测试使用库，因为它可能更有效并且已经为此唯一目的进行了调试。例如JMH、Caliper或Bill 和 Paul 的优秀 UCSD Benchmarks for Java。

于 2009-02-04T20:49:28.043 回答
256

我知道这个问题已被标记为已回答，但我想提两个帮助我们编写微基准测试的库

来自谷歌的卡尺

入门教程

  1. http://codingjunkie.net/micro-benchmarking-with-caliper/
  2. http://vertexlabs.co.uk/blog/caliper

来自 OpenJDK 的 JMH

入门教程

  1. 避免 JVM 上的基准测试陷阱
  2. 使用 JMH 进行 Java 微基准测试
  3. JMH简介
于 2010-12-18T23:35:07.853 回答
92

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

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

我正在撰写有关 .NET 基准测试框架设计的博客。我有几个较早的帖子可能会给您一些想法 - 当然，并非所有内容都合适，但其中一些可能是合适的。

于 2009-02-02T17:46:59.193 回答
49

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

jmh 是一个 Java 工具，用于构建、运行和分析用 Java 和其他针对 JVM 的语言编写的纳米/微型/宏观基准。

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

也可以看看：

于 2013-04-03T12:32:49.617 回答
23

基准测试应该测量时间/迭代还是迭代/时间，为什么？

这取决于您要测试的内容。

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

于 2009-02-02T19:54:35.787 回答
16

如果您尝试比较两种算法，请为每种算法至少做两个基准测试，交替顺序。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 秒左右。迭代次数越多，基准时间中的重要数字就越多，数据就越可靠。

于 2009-02-02T17:57:01.200 回答
16

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

于 2009-02-02T18:00:10.260 回答
13

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

首先：您必须计算各种花费时间或多或少随机的事件：垃圾收集、缓存效果（文件的 OS 和 CPU 的内存）、IO 等。

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

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

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

于 2009-02-02T17:46:59.583 回答
8

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

这是因为A在大多数基准测试运行期间，实现可能比实现更快B。但A也可能具有更高的分布，因此A与B.

因此，正确编写和运行微基准测试也很重要，而且要正确分析它。

于 2013-01-21T14:04:05.993 回答
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");
于 2017-03-19T19:21:23.860 回答
7

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

于 2010-12-18T23:22:11.887 回答