跳至正文

基准测试

该软件包提供了一些基准测试来了解其性能如何。这有助于了解新功能或重构是否会降低性能。

运行基准测试

在您的计算机上安装该项目后,您可以运行:

composer run-script benchmark

这将运行所有基准测试并产生如下输出:

有趣的信息位于底部的表格中。

这是包含正在运行的基准测试的类名。这里MapperBench对应于位于qa/Benchmark/MapperBench.php的\CuyZ\Valinor\QA\Benchmark\MapperBench类。

这是基准类中的方法名称。这里的readme对应于\CuyZ\Valinor\QA\Benchmark\MapperBench::readme()

这就是转数。这是连续调用主题的次数。

默认情况下,该项目运行它们 1000 次以获得良好的平均值。每个主题的执行时间都是微秒或毫秒,这意味着每次运行之间很容易出现很大的差异。转数越高,基准越稳定。

热身

在对一个主题进行测试之前,它会运行一次,但这次革命现在已包含在统计数据中。

由于 Composer 类自动加载的影响,第一次运行在这里。这次运行将首先遇到一个类并require它,这意味着进行 IO。但一旦加载,后续的革命将不会完成 IO 部分。

这意味着该模式中看到的时间不包括自动加载时间。因此它并不能完全反映在最终用户项目中可以观察到的真实执行时间。但由于该项目不会影响 Composer 加载类所需的时间,因此可以不将其包含在这些基准测试中。

这是迭代次数。它是运行主题的进程数。

默认情况下,项目运行它们 10 次。这意味着每次迭代都会运行subject 1000 次,总共调用 10000 次。

就像革命一样,多次迭代可以得到更好的模式。

在所有革命和迭代中测试该主题所需的最大内存。

这是运行该主题所需的平均时间。

本质上,它是 10000 次调用执行时间的总和除以 10000。

这是迭代之间的时间偏差。高百分比意味着每次迭代的执行时间与其他迭代有很大不同。这可能表明代码是不确定的,意味着每次旋转运行不同的代码或受到 IO 操作的影响。

如文档中所示,该值应低于 2%。

与基线比较

如上所述,基准测试的目标是了解某些新代码是否会导致性能下降。

您首先需要创建一个基线。这是运行基准测试并存储结果。这是通过以下命令完成的:

composer run-script benchmark-baseline

然后就可以在项目中进行你想要的代码修改了。要知道您是否引入了回归,请运行:

composer run-script benchmark-compare

如果发生回归,它将产生如下输出:

在mem_peak 、 mode和rstdev列中,您将找到一个新的百分比,指示代码与基线之间的差异。

如果任何主体的平均执行时间超过基准时间(误差幅度在 10% 以内),则该命令将失败。

为了简化您的生活,当您对此项目打开 Pull 请求时,会自动运行此基准比较。

如果出现回归,CI 就会失败。

注意

由于rstdev值在基线中应尽可能低,任何轻微的变化都会使比较差异百分比变高。因此,此列中的任何红色值并不一定意味着存在问题。

这也是为什么没有断言这个值的原因。