Question

我感兴趣的是比较两种不同功能的速度，对两种功能使用相同的输入数据（BMP）。

当我们测量函数的执行时间（使用始终相同的输入）时，即使我们应该得到相同的结果（时间），因为程序在多任务环境中运行。即使我们将我们的计划作为“高优先级”来运行。来自其他程序的一些干扰会减慢我们的程序（为了简化考虑单核计算机）。

因此，大多数人会多次计时并平均。我的问题是为什么我们不记录最短的执行时间而不是平均值？最小执行时间应该比平均执行时间更接近实际情况。

Answer 1

你应该始终瞄准最短时间因为如果你这样做，你确定你只是为你自己的代码计时而没有别的。

瞄准最短时间
如果您的代码只有一个执行路径，那么您应该始终将最短时间（多次重复）视为实际时间。
这样，您可以在一到两个CPU周期内获得准确的时序。为了清楚起见，您运行数百万次运行的代码片段并将该运行的最低样本作为时间然后将这些数百万次运行包装在一个运行10x或100x的循环中，并再次采用最低时序。像这样：

Lowest = MaxInt;
loop 100x 
  loop million times
     Clock.Start;
     DoTest;
     Timing = Clock.Time;
     if (timing < Lowest) {Lowest = timing}

另一个循环重置有时有帮助的上下文。这很重要如果JIT编译器迟到了。外部循环使其更改为重置。

如果代码片段速度特别快，您还可以在外循环中进行定时，然后除以一百万。在这种情况下，您将运行一个额外的空时序循环，并从繁忙循环中所用的时间中减去空循环所用的时间。
你必须聪明一点，以防止代码优化消除空循环:-)。

如果您的代码有多个可能的路径，那么您无法真正计算其执行时间。只运行一个带有固定输入的简单循环，因为这只会给你一个代码路径的部分时间。这可能无法代表现实世界的表现。

确保您的运行具有决定性
始终尝试修复代码，以便代码只能使用一条路径或者尝试设置测试，以便连续采用所有可能的路径，然后计算所有内容所需的最短时间，并除以测试的代码路径数。

所有东西和厨房水槽分析
如果那是不可能的，你将不得不取平均值，但请注意，在这种情况下，你不再仅仅计算你的代码，你还要考虑系统开销，硬盘中断和后台进程。

我们应该测量函数的平均或最短执行时间吗？

1 个答案: