我正在尝试使用java创建基准测试。目前我有以下简单的方法:
public static long runTest(int times){
long start = System.nanoTime();
String str = "str";
for(int i=0; i<times; i++){
str = "str"+i;
}
return System.nanoTime()-start;
}
我目前在另一个循环中多次进行此循环,该循环多次发生并获得运行此方法所需的最小/最大/平均时间。然后我在另一个线程上开始一些活动并再次测试。基本上我只想获得一致的结果......如果我有一千万次runTest循环,它似乎非常一致:
Number of times ran: 5
The max time was: 1231419504 (102.85% of the average)
The min time was: 1177508466 (98.35% of the average)
The average time was: 1197291937
The difference between the max and min is: 4.58%
Activated thread activity.
Number of times ran: 5
The max time was: 3872724739 (100.82% of the average)
The min time was: 3804827995 (99.05% of the average)
The average time was: 3841216849
The difference between the max and min is: 1.78%
Running with thread activity took 320.83% as much time as running without.
但这看起来有点多,需要一些时间......如果我在runTest循环中尝试较低的数字(100000)......它开始变得非常不一致:
Number of times ran: 5
The max time was: 34726168 (143.01% of the average)
The min time was: 20889055 (86.02% of the average)
The average time was: 24283026
The difference between the max and min is: 66.24%
Activated thread activity.
Number of times ran: 5
The max time was: 143950627 (148.83% of the average)
The min time was: 64780554 (66.98% of the average)
The average time was: 96719589
The difference between the max and min is: 122.21%
Running with thread activity took 398.3% as much time as running without.
我有没有办法像这样做一致,有效/快速的基准?
顺便说一句,我没有测试开始和结束时间之间的代码。我正在以某种方式测试CPU负载(请参阅我如何开始一些线程活动并重新测试)。所以我认为我正在寻找的东西替代我在“runTest”中的代码,它将产生更快,更一致的结果。
由于
答案 0 :(得分:5)
简而言之:
(Micro-)基准测试非常复杂,因此使用像Benchmarking framework http://www.ellipticgroup.com/misc/projectLibrary.zip这样的工具 - 并且仍然对结果持怀疑态度(“将微信任放在微基准中”,Cliff博士请点击)。
详细说明:
有很多因素可以强烈影响结果:
Brent Boyer的文章“健壮的Java基准测试,第1部分:问题”(http://www.ibm.com/developerworks/java/library/j-benchmark1/index.html)是对所有这些问题的良好描述以及您是否可以对它们做什么(例如,使用JVM选项或事先调用ProcessIdleTask)
您将无法消除所有这些因素,因此进行统计数据是一个好主意。但是:
上述基准框架(http://www.ellipticgroup.com/misc/projectLibrary.zip)使用这些技术。您可以在Brent Boyer的文章“Robust Java benchmarkinging,Part 2:Statistics and solutions”(https://www.ibm.com/developerworks/java/library/j-benchmark2/)中阅读它们。
答案 1 :(得分:1)
您的代码最终主要测试垃圾收集性能,因为在循环中附加到String最终会创建并立即丢弃大量越来越大的String对象。
这本身就会导致测量结果发生巨大变化,并受到多线程活动的影响。
我建议你在循环中做一些具有更可预测性能的东西,比如数学计算。
答案 2 :(得分:0)
在1000万次运行中,HotSpot编译器检测到“使用频繁”的代码并将其编译为机器本机代码的可能性很大。
解释了JVM字节码,这导致它容易受到JVM中发生的其他后台进程的更多中断(如垃圾收集)。
一般来说,这些基准充满了不成立的假设。如果没有大量证据证明初始测量(时间)实际上并未测量您的任务以及可能的其他后台任务,您无法相信微观基准确实证明了它的目的。如果您不尝试控制后台任务,那么测量就不那么有用了。