基准方法调用c[副本]

你可以用内置的 Stopwatch class “提供一组方法和属性,您可以使用这些方法和属性来精确地测量经过的时间。”如果您正在寻找一种手动的方法。但在自动化方面不确定。

从尤里的回答中偷走(并修改):

private static void Benchmark(Action act, int iterations)
{
    GC.Collect();
    act.Invoke(); // run once outside of loop to avoid initialization costs
    Stopwatch sw = Stopwatch.StartNew();
    for (int i = 0; i < iterations; i++)
    {
        act.Invoke();
    }
    sw.Stop();
    Console.WriteLine((sw.ElapsedMilliseconds / iterations).ToString());
}

通常,一个特定的方法必须初始化一些东西,而您并不总是希望在整个基准测试中包含这些初始化成本。另外,您希望将总的执行时间除以迭代次数,这样您的估计多少与迭代次数无关。

我从乔恩·斯基特的基准测试方法中窃取了以下大部分内容:

private static void Benchmark(Action act, int interval)
{
    GC.Collect();
    Stopwatch sw = Stopwatch.StartNew();
    for (int i = 0; i < interval; i++)
    {
        act.Invoke();
    }
    sw.Stop();
    Console.WriteLine(sw.ElapsedMilliseconds);
}

以下是我通过试验和错误发现的一些东西。

1. 放弃第一批(数千)次迭代。他们很可能会受到抖动的影响。
2. 在单独的 Thread 对象可以提供更好、更稳定的结果。我不知道为什么。
3. 我见过一些人用 Thread.Sleep 在执行基准之前,无论出于什么原因。这只会使事情变得更糟。我不知道为什么。可能是因为抖动。
4. 不要在启用调试的情况下运行基准测试。代码运行的速度很可能会慢一个数量级。
5. 在启用所有优化的情况下编译应用程序。某些代码可能会受到优化的严重影响,而其他代码则不会,因此在没有优化的情况下编译会影响基准的可靠性。
6. 在启用优化的情况下编译时,有时需要以某种方式评估基准的输出(例如打印值等)。否则,编译器可能会“发现”一些计算是无用的,并且不会执行它们。
7. 在执行某些基准时,委托的调用可能会有明显的开销。最好在委托中放置多个迭代,这样开销对基准的结果影响很小。
8. 分析人员可以有自己的开销。他们擅长告诉您代码的哪些部分是瓶颈,但实际上他们不擅长可靠地确定两个不同的东西的基准。
9. 一般来说,花哨的基准测试解决方案会有明显的开销。例如,如果您希望使用一个接口对多个对象进行基准测试,那么将每个对象包装在一个类中是很有吸引力的。但是,请记住,类构造函数也有必须考虑的开销。最好尽可能简单直接。

听起来你想要一个 profiler . 我强烈推荐 EQATEC profiler 我自己,这是我试过的最好的自由。与简单的秒表相比,这种方法的好处在于它还提供了对某些方法/块的性能的细分。

分析程序提供了最好的基准,因为它们诊断了所有代码,但是它们会大大降低速度。轮廓仪用于发现瓶颈。

为了优化算法,当您知道瓶颈在哪里时,可以使用名为>秒表的字典,在运行时跟踪性能关键部分。