您如何用Java编写（并运行）正确的微基准测试？
我正在寻找一些代码示例和注释，以说明要考虑的各种问题。
示例：基准测试应测量时间/迭代或迭代/时间，为什么？
相关： 秒表基准测试是否可以接受？
#1楼
还应注意，比较不同的实现时，分析微型基准测试的结果也可能很重要。 因此，应该进行显着性检验 。
这是因为在基准测试的大多数运行中，实现A可能比实现B更快。 但是A可能还具有较高的价差，因此与B相比， A的测量性能优势没有任何意义。
因此，正确编写和运行微基准测试以及正确分析它也很重要。
#2楼
jmh是OpenJDK的最新成员，由Oracle的一些性能工程师编写。 当然值得一看。
jmh是一种Java工具，用于构建，运行和分析以Java和其他针对JVM的语言编写的nano / micro / macro基准测试。
样本测试注释中隐藏了非常有趣的信息。
也可以看看：
#3楼
除了其他出色的建议，我还请注意以下几点：
对于某些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");
#4楼
http://opt.sourceforge.net/ Java Micro Benchmark-确定不同平台上计算机系统的比较性能特征所需的控制任务。 可用于指导优化决策并比较不同的Java实现。
#5楼
我知道这个问题已被标记为已回答，但我想提两个可以帮助我们编写微基准测试的库
入门教程
入门教程
- 避免在JVM上进行基准测试陷阱
- http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking
- http://java-performance.info/jmh/
#6楼
Java基准测试的重要事项是：
- 首先对JIT进行热身，方法是在计时之前多次运行代码
- 确保运行足够长的时间，以便能够在几秒钟或更好的几十秒内测量结果
- 虽然不能在
System.gc()迭代之间调用System.gc()，但最好在测试之间运行它，以便每个测试都有望获得一个“干净的”内存空间来使用。 （是的，gc()不仅仅是一个提示，而不是一个保证，但是根据我的经验，它很有可能真的会进行垃圾回收。） - 我喜欢显示迭代次数和时间，以及可以缩放的时间/迭代分数，以使“最佳”算法的分数为1.0，其他分数则以相对方式进行评分。 这意味着您可以长时间运行所有算法，同时改变迭代次数和时间，但仍可获得可比的结果。
我只是在撰写有关.NET中基准测试框架设计的博客。 我有一对夫妇的较早的帖子这或许可以给你一些想法-而不是一切都将是合适的，当然，但它的一些可能。
#7楼
用Java编写微基准有很多可能的陷阱。
第一：您必须计算各种事件，这些事件或多或少地需要时间，这些时间是：垃圾收集，缓存效果（文件用于OS，内存用于CPU），IO等。
第二：您不能相信很短的时间间隔内测量时间的准确性。
第三：JVM在执行时优化您的代码。 因此，在同一个JVM实例中的不同运行将变得越来越快。
我的建议：使基准测试运行几秒钟，这比运行时间（毫秒）要可靠。 预热JVM（这意味着至少要运行一次基准测试而不进行测量，JVM才能运行优化）。 并多次运行基准测试（可能是5次），并取中值。 在新的JVM实例中运行每个微基准测试（调用每个基准测试新Java），否则JVM的优化效果会影响以后运行的测试。 不要执行在预热阶段未执行的事情（因为这可能会触发类加载和重新编译）。
#8楼
如果要比较两种算法，请为每种算法至少执行两个基准测试，以交替顺序。 即：
for(i=1..n)
alg1();
for(i=1..n)
alg2();
for(i=1..n)
alg2();
for(i=1..n)
alg1();
我发现相同算法在不同遍中的运行时有一些明显的差异（有时为5-10％）。
另外，请确保n非常大，以便每个循环的运行时间至少在10秒左右。 迭代次数越多，基准时间中的数字就越大，数据越可靠。
#9楼
确保以某种方式使用在基准代码中计算的结果。 否则，您的代码可以被优化掉。
#10楼
基准测试应该测量时间/迭代次数还是迭代/时间，为什么？
这取决于你正在尝试测试。
如果您对延迟感兴趣，请使用时间/迭代，如果您对吞吐量感兴趣，请使用迭代/时间。
#11楼
有关从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编译，并带有一个at符号表示非初始入口点，例如： 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和Paul的Java优秀UCSD基准 。
扫一扫
793
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
