在 C# 中对小代码示例进行基准测试，这个实现可以改进吗？

Question

我发现自己经常对一小段代码进行基准测试，以查看哪种实现最快。

我经常看到基准代码不考虑jitting 或垃圾收集器的cmets。

我有以下简单的基准测试功能，我已经慢慢进化了：

  static void Profile(string description, int iterations, Action func) {
        // warm up 
        func();
        // clean up
        GC.Collect();

        var watch = new Stopwatch();
        watch.Start();
        for (int i = 0; i < iterations; i++) {
            func();
        }
        watch.Stop();
        Console.Write(description);
        Console.WriteLine(" Time Elapsed {0} ms", watch.ElapsedMilliseconds);
    }

用法：

Profile("a descriptions", how_many_iterations_to_run, () =>
{
   // ... code being profiled
});

这个实现有什么缺陷吗？是否足以证明实现 X 比实现 Y 在 Z 迭代中更快？你能想出什么方法来改善这一点吗？

编辑 很明显，基于时间的方法（而不是迭代）是首选，是否有人有任何实现时间检查不影响性能的实现？

Answer 1

这是修改后的功能：根据社区的建议，请随时修改此社区 wiki。

static double Profile(string description, int iterations, Action func) {
    //Run at highest priority to minimize fluctuations caused by other processes/threads
    Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
    Thread.CurrentThread.Priority = ThreadPriority.Highest;

    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();
    }
    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
    return watch.Elapsed.TotalMilliseconds;
}

确保您在启用优化的版本中编译，并在 Visual Studio 之外运行测试。最后一部分很重要，因为 JIT 通过附加的调试器限制其优化，即使在发布模式下也是如此。

Answer 2

最终确定不一定会在GC.Collect 返回之前完成。完成排队，然后在单独的线程上运行。该线程可能在您的测试期间仍然处于活动状态，从而影响结果。

如果您想在开始测试之前确保完成完成，那么您可能需要调用GC.WaitForPendingFinalizers，这将阻塞直到完成队列被清除：

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

Answer 3

如果您想将 GC 交互排除在等式之外，您可能希望在 GC.Collect 调用之后运行“热身”调用，而不是之前。这样你就知道 .NET 已经为你的函数的工作集从操作系统分配了足够的内存。

请记住，您正在为每次迭代进行非内联方法调用，因此请确保将您正在测试的内容与空主体进行比较。您还必须接受，您只能可靠地为比方法调用长几倍的事情计时。

此外，根据您要分析的内容类型，您可能希望基于计时运行一定时间而不是一定次数的迭代 - 这往往会导致更容易 -可比较的数字，而不必为最佳实施安排很短的时间和/或为最坏的实施安排很长的时间。

Answer 4

我会完全避免传递委托：

1. 委托调用是~虚拟方法调用。不便宜：大约 .NET 中最小内存分配的 25%。如果您对详细信息感兴趣，请参阅e.g. this link。
2. 匿名委托可能会导致使用闭包，您甚至不会注意到这一点。同样，访问闭包字段明显比例如访问堆栈上的变量。

导致闭包使用的示例代码：

public void Test()
{
  int someNumber = 1;
  Profiler.Profile("Closure access", 1000000, 
    () => someNumber + someNumber);
}

如果您不了解闭包，请查看 .NET Reflector 中的此方法。

Answer 5

我认为像这样的基准测试方法最难克服的问题是考虑边缘情况和意外情况。例如 - “这两个代码 sn-ps 如何在高 CPU 负载/网络使用/磁盘抖动/等下工作。”它们非常适合进行基本逻辑检查，以查看特定算法是否明显比另一种算法运行得更快。但是要正确测试大多数代码性能，您必须创建一个测试来测量该特定代码的特定瓶颈。

我仍然想说，测试小块代码通常没有什么投资回报，并且会鼓励使用过于复杂的代码而不是简单的可维护代码。编写其他开发人员或我自己 6 个月后可以快速理解的清晰代码将比高度优化的代码具有更多的性能优势。

Answer 6

我会多次致电func() 进行热身，而不仅仅是一次。

Answer 7

改进建议

1. 检测执行环境是否适合进行基准测试（例如检测是否附加了调试器或是否禁用了 jit 优化，这会导致测量不正确）。

2. 独立测量部分代码（准确查看瓶颈所在）。

3. 比较不同版本/组件/代码块（在您的第一句话中，您说“...对小块代码进行基准测试以查看哪个实现最快。”）。

关于#1：

• 要检测是否附加了调试器，请读取属性System.Diagnostics.Debugger.IsAttached（请记住还要处理最初未附加调试器但一段时间后附加的情况）。

• 要检测是否禁用了 jit 优化，请读取相关程序集的属性 DebuggableAttribute.IsJITOptimizerDisabled：

  private bool IsJitOptimizerDisabled(Assembly assembly)
  {
      return assembly.GetCustomAttributes(typeof (DebuggableAttribute), false)
          .Select(customAttribute => (DebuggableAttribute) customAttribute)
          .Any(attribute => attribute.IsJITOptimizerDisabled);
  }
  

关于#2：

这可以通过多种方式完成。一种方法是允许提供多个代表，然后单独测量这些代表。

关于#3：

这也可以通过多种方式完成，不同的用例需要非常不同的解决方案。如果手动调用基准测试，那么写入控制台可能没问题。但是，如果基准测试是由构建系统自动执行的，那么写入控制台可能就不那么好了。

执行此操作的一种方法是将基准测试结果作为强类型对象返回，该对象可以在不同的上下文中轻松使用。

---

Etimo.Benchmarks

另一种方法是使用现有组件来执行基准测试。实际上，在我的公司，我们决定将我们的基准测试工具发布到公共领域。它的核心是管理垃圾收集器、抖动、预热等，就像这里的其他一些答案所建议的那样。它还具有我上面建议的三个功能。它管理了Eric Lippert blog 中讨论的几个问题。

这是一个示例输出，其中比较了两个组件并将结果写入控制台。在这种情况下，比较的两个组件称为“KeyedCollection”和“MultiplyIndexedKeyedCollection”：

有一个NuGet package，一个sample NuGet package，源代码位于GitHub。还有一个blog post。

如果您赶时间，我建议您获取示例包并根据需要简单地修改示例代表。如果您不着急，最好阅读博文以了解详细信息。

Answer 8

您还必须在实际测量之前运行“热身”通道，以排除 JIT 编译器花在 jitting 代码上的时间。

Answer 9

根据您进行基准测试的代码及其运行平台，您可能需要考虑how code alignment affects performance。这样做可能需要一个多次运行测试的外部包装器（在不同的应用程序域或进程中？），有些时候首先调用“填充代码”来强制它被 JIT 编译，从而导致代码被基准以不同方式对齐。完整的测试结果将为各种代码对齐提供最佳情况和最差情况的时序。

Answer 10

如果您试图从基准测试中消除垃圾收集影响，是否值得设置GCSettings.LatencyMode？

如果不是，并且您希望在 func 中创建的垃圾的影响成为基准的一部分，那么您不应该在测试结束时（在计时器内）强制收集吗？

Answer 11

您的问题的基本问题是假设单个 测量可以回答你所有的问题。你需要测量 多次有效地了解情况并 尤其是在像 C# 这样的垃圾收集语言中。

另一个答案给出了衡量基本性能的好方法。

static void Profile(string description, int iterations, Action func) {
    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();
    }
    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
}

但是，这个单一的测量并没有考虑到垃圾 收藏。适当的配置文件还解释了最坏情况下的性能 垃圾收集分布在许多调用中（这个数字是排序的 无用，因为 VM 可以终止而无需收集剩余的 垃圾，但仍可用于比较两个不同的 func 的实现。）

static void ProfileGarbageMany(string description, int iterations, Action func) {
    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();
    }
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
}

而且人们可能还想测量最坏情况下的性能 只调用一次的方法的垃圾回收。

static void ProfileGarbage(string description, int iterations, Action func) {
    // warm up 
    func();

    var watch = new Stopwatch(); 

    // clean up
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();

    watch.Start();
    for (int i = 0; i < iterations; i++) {
        func();

        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
    }
    watch.Stop();
    Console.Write(description);
    Console.WriteLine(" Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds);
}

但比推荐任何具体的可能的补充更重要 测量来描述是一种应该测量多个的想法 不同的统计数据，而不仅仅是一种统计数据。