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

StackOverflow https://stackoverflow.com/questions/504103

题

如何用 Java 编写（并运行）正确的微基准测试？

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

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

有关的： 秒表基准测试可以接受吗？

有帮助吗？

解决方案

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

规则 0： 阅读有关 JVM 和微基准测试的著名论文。好的一个是 布莱恩·戈茨，2005. 。不要对微基准抱有太大期望；它们仅测量有限范围的 JVM 性能特征。

规则1： 始终包含一个自始至终运行测试内核的预热阶段，足以在计时阶段之前触发所有初始化和编译。（在预热阶段较少的迭代是可以的。经验法则是进行数万次内循环迭代。）

规则 2： 始终与 -XX:+PrintCompilation, -verbose:gc, 等等，这样您就可以验证编译器和 JVM 的其他部分在计时阶段没有执行意外的工作。

规则 2.1： 在计时和预热阶段的开始和结束时打印消息，以便您可以验证计时阶段期间规则 2 没有输出。

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

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

规则 5： 注意去优化和重新编译的影响。不要在计时阶段第一次采用任何代码路径，因为编译器可能会根据之前根本不会使用该路径的乐观假设，垃圾并重新编译代码。规则 2 是抵御此类影响的第一道防线。

规则 6： 使用适当的工具来了解编译器的想法，并期望对其生成的代码感到惊讶。在形成关于是什么使某些东西变得更快或更慢的理论之前，请亲自检查代码。

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

规则 8： 使用库进行基准测试，因为它可能更有效，并且已经为此唯一目的进行了调试。例如 杰玛赫, 卡尺 或者 Bill 和 Paul 的优秀 UCSD Java 基准.

其他提示

Java 基准测试的重要内容是：

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

我正在撰写有关 .NET 基准测试框架设计的博客。我有一个 夫妻 的 较早的帖子 这也许能给你一些想法——当然，并不是所有的东西都是合适的，但其中一些可能是合适的。

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

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

埋藏着非常有趣的信息 样本测试评论.

也可以看看：

  

如若基准测量时间/迭代或迭代/时间，为什么？

这取决于什么您正在试图测试。

如果您有兴趣的延迟后，使用时间/迭代，如果你有兴趣的吞吐量后，使用迭代/时间。

请确保您以某种方式使用其计算的基准代码的结果。否则，代码可以被优化了。

如果您要比较两个算法，这样做至少有两个基准为每个交替的顺序。即：

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

我已经发现在相同的算法的运行时间的一些明显的差异（有时5-10％）在不同的道次..

此外，确保名词的是非常大的，使得每个循环的运行时间是至少是10秒左右。的更多的迭代，在基准时间越显著附图和更可靠的数据是

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

第一条：您有需要时间或多或少随机各种事件来计算：垃圾收集，（文件和CPU对内存的操作系统），IO等

缓存影响。

第二：你不能相信所测得的时间的精度非常短的间隔

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

我的建议：让您的基准测试程序运行几秒钟，比运行时在毫秒更可靠。预热JVM（而不测量运行基准测试至少一次的装置，该JVM可以运行优化）。并运行基准多次（也许5次），并采取中间值。运行在一个新的JVM实例每个微基准测试（要求每一个标杆新的Java），否则JVM的优化效果会影响以后运行测试。不执行的东西，那未在预热阶段执行（因为这可能会引发类负载和重新编译）。

还应当指出的是，它也可能是重要的比较不同的实施方式中时，分析所述微基准测试的结果。因此一个显着性检验应。

这是因为实施A可能是在大多数基准不是实施B的运行速度更快。但A也可能在与A相比，具有更高的传播，使B的测量性能优势将不具有任何意义。

因此，同样重要的是写和正确运行一个微基准测试，而且正确地进行分析。

http://opt.sourceforge.net/ 爪哇微基准测试 - 所需的控制任务以确定所述比较在不同平台上的计算机系统的性能特点。可用于指导优化决策，并比较不同的Java实现。

要添加到其它优良建议，我还牢记以下的：

有关某些CPU（例如Intel酷睿范围与TurboBoost睿），温度（和目前正在使用核的数量，以及thier利用率百分比）影响的时钟速度。由于CPU是主频动态，这可能会影响你的结果。例如，如果你有一个单线程应用中，最大时钟速度（与TurboBoost睿）比使用所有核心应用更高。因此，这可以与在某些系统单和多线程性能比较干扰。记住的是，温度和volatages也影响涡轮多久频率被维持。

也许你有过直接控制一个更为根本的重要方面：确保你测量正确的事！例如，如果你使用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");
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top