C#：这个基准测试类准确吗？

Question

我创建了一个简单的类来对我的一些方法进行基准测试。但它准确吗？我对基准测试、时间安排等有点陌生，所以我想我可以在这里寻求一些反馈。另外，如果它很好，也许其他人也可以使用它:)

public static class Benchmark
{
    public static IEnumerable<long> This(Action subject)
    {
        var watch = new Stopwatch();
        while (true)
        {
            watch.Reset();
            watch.Start();
            subject();
            watch.Stop();
            yield return watch.ElapsedTicks;
        }
    }
}

你可以这样使用它：

var avg = Benchmark.This(() => SomeMethod()).Take(500).Average();

有什么反馈吗？它看起来是不是相当稳定和准确，还是我遗漏了什么？

Answer 1

它与简单的基准测试一样准确。但有些因素不是你能控制的：

• 从其他进程加载到系统
• 基准测试之前/期间的堆状态

您可以对最后一点做点什么，基准测试是可以捍卫调用GC.Collect 的罕见情况之一。您可以事先致电subject 一次以消除任何 JIT 问题。但这需要对subject 的调用是独立的。

public static IEnumerable<TimeSpan> This(Action subject)
{
    subject();     // warm up
    GC.Collect();  // compact Heap
    GC.WaitForPendingFinalizers(); // and wait for the finalizer queue to empty

    var watch = new Stopwatch();
    while (true)
    {
        watch.Reset();
        watch.Start();
        subject();
        watch.Stop();
        yield return watch.Elapsed;  // TimeSpan
    }
}

对于奖金，你的班级应该检查System.Diagnostics.Stopwatch.IsHighResolution field。如果它关闭，则只有非常粗略（20 毫秒）的分辨率。

但在普通 PC 上，后台运行着许多服务，它永远不会很准确。

Answer 2

您绝对应该返回 ElapsedMilliseconds 而不是 ElapsedTicks。 ElapsedTicks 返回的值取决于秒表频率，在不同的系统上可能不同。它不一定对应于 Timespan 或 DateTime 对象的 Ticks 属性。

见http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.elapsedticks.aspx。

如果你确实想要Ticks的额外分辨率，你应该返回watch.Elapsed.Ticks（即Timestamp.Ticks）而不是watch.ElapsedTicks（这可能是最微妙的潜力之一 .Net 中的错误）。来自 MSDN：

秒表刻度不同于 日期时间。滴答声。中的每个刻度 DateTime.Ticks 值代表一个 100 纳秒间隔。每个打勾 ElapsedTicks 值表示 时间间隔等于 1 秒 除以频率。

除此之外，我想您的代码很好，尽管我认为您会在测量中包含一些方法调用开销，如果方法本身执行时间很短，这可能会很重要。此外，您可能希望从计算的平均值中排除对该方法的第一次调用，但我不确定您在课堂上如何做到这一点。

最后一点，这可能与此类的大多数用途无关：与系统时间相比，秒表的运行速度有点快。在我的计算机上，24 小时后它会提前大约 5 秒（即 秒，而不是毫秒），而在其他机器上，这种偏差可能更大。所以说它非常准确有点误导，而实际上它只是高度精细。对于时间短的方法，这显然不是一个大问题。

还有最后一点，这肯定与 相关：我在进行基准测试时经常注意到，我会得到一堆运行时间，这些运行时间都聚集在一个狭窄的值范围内（例如80、80、79、82 等），但偶尔会在 Windows 中发生其他事情（比如打开另一个程序或我的防病毒软件启动或其他事情），我会得到一个与其他人完全不同的值（例如80、80、79、271、80 等）。我认为解决这个异常值问题的一个简单方法是使用测量的中值而不是均值。我不知道 Linq 是否自动支持。

Answer 3

这里有几个问题。

首先，请记住，第一次运行代码时，其方法调用的传递闭包将被 jitted。这意味着第一次运行的成本可能比随后的每次运行都高。根据您是对“冷”时间还是“热”时间进行基准测试，这可能会有所不同。我见过一些方法，其中 jitting 方法的成本比其他所有调用的成本加起来都要高！

其次，请记住垃圾收集器在另一个线程上运行。如果您在一次运行中制造垃圾，那么清理垃圾的成本可能要到后续运行才能实现。因此，您没有考虑一次运行的总成本，而是将其强加到以后的运行中。

这两者都表明所有基准测试的弱点：基准测试本质上是不切实际的，因此价值有限。在实际代码中，GC 将运行，抖动将运行，等等。通常情况下，基准性能与现实世界的性能完全不同，因为基准没有考虑到大型系统固有的现实世界成本的可变性。与其孤立地分析性能特征，我更喜欢看真实客户实际面临的现实场景的性能特征。

Answer 4

由于我不是 C# 程序员，我无法准确地说该类是否适合计算函数执行所需的时间。但是，为了可重复性和准确性，需要注意一些事项。

我不了解 .NET Framework 的各种细节，但取决于它如何编译为本机代码，任何编译都可能会影响基准测试结果。此外，一个函数是否在缓存中也会产生影响。因此，您需要循环遍历您的函数，以确保编译没有命中，并且所有内容都已加载并准备就绪。完成后，您就可以开始了。

其他人可能比我拥有更好的 .NET 信息和知识。