java - JMH - 奇怪的基准测试结果

Question

我正在使用 JMH 对 DOM 解析器进行基准测试。我得到了非常奇怪的结果，因为第一次迭代实际上比后面的迭代运行得更快





谁能解释为什么会发生这种情况？另外，百分位数和所有数字是什么意思，为什么它在第三次迭代后开始变得稳定？一次迭代是否意味着整个基准测试方法的一次迭代？下面是我正在运行的方法

@Benchmark 
@BenchmarkMode(Mode.SingleShotTime) 
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 13, time = 1, timeUnit = TimeUnit.MILLISECONDS)
public void testMethod_no_attr() {
    try {
        File fXmlFile = new File("500000-6.xml");
        DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
        DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
        Document doc = dBuilder.parse(fXmlFile);
    } catch (Exception  e) {
        e.printStackTrace();  
    }
}

Answer 1

这些 百分位数具有可怕的误导性 .不要使用它们。

如果您有 N = 10 ，难怪所有的底值都一样。
因为你的样本太少，无法谈论 99.999% 的分位数。我在这里实际考虑的唯一值是中位数(50% 分位数)，最终是 IQR(四分位间距)。

如果您乐观，您会假设最慢的样本是 95%。如果您不太乐观，请将 N=10 的最慢样本视为 90% 分位数。如果您更认真地对待这些估计，您可以将间距视为表示约。 1/sqrt(N-1)，即假设高达 33% 的运行甚至比最慢的样本 N=10 还要慢.您需要更多样本来缩小这些估计范围!任何超过 95% 的都只是猜测。 99% - 你无法回答那里发生的事情。你只是没有足够的数据。

正如所呈现的，这些值只是彻头彻尾的胡说八道。 根据数据，您无法估计 P(99,9999)=某物。这个数字相当于百万分之一的运行比这更糟糕。但是你只做了 10 个，不要用这个小 N 来预测如果你有一百万会发生什么。 JMH 不应为小 N 打印这些极端分位数。