4

最近我读到了关于性能的早期和经常测量,第 2 部分,它带有源代码二进制文件

文章摘录:“我强调,要可靠地创建高性能程序,您需要了解在设计过程的早期使用的各个组件的性能”。

因此,我使用他的工具 (v0.2.2) 进行基准测试并尝试查看各个组件的性能。

在我的PC(x64)下,结果如下:

Name                                                                            Median  Mean    StdDev  Min     Max Samples
NOTHING [count=1000]                                                            0.14    0.177   0.164   0       0.651   10
MethodCalls: EmptyStaticFunction() [count=1000 scale=10.0]                      1       1.005   0.017   0.991   1.042   10
Loop 1K times [count=1000]                                                      85.116  85.312  0.392   84.93   86.279  10
MethodCalls: EmptyStaticFunction(arg1,...arg5) [count=1000 scale=10.0]          1.163   1.172   0.015   1.163   1.214   10
MethodCalls: aClass.EmptyInstanceFunction() [count=1000 scale=10.0]             1.009   1.011   0.019   0.995   1.047   10
MethodCalls: aClass.Interface() [count=1000 scale=10.0]                         1.112   1.121   0.038   1.098   1.233   10
MethodCalls: aSealedClass.Interface() (inlined) [count=1000 scale=10.0]         0       0.008   0.025   0       0.084   10
MethodCalls: aStructWithInterface.Interface() (inlined) [count=1000 scale=10.0] 0       0.008   0.025   0       0.084   10
MethodCalls: aClass.VirtualMethod() [count=1000 scale=10.0]                     0.674   0.683   0.025   0.674   0.758   10
MethodCalls: Class.ReturnsValueType() [count=1000 scale=10.0]                   2.165   2.16    0.033   2.107   2.209   10

我很惊讶地看到虚拟方法(0.674)比非虚拟实例方法(1.009)或静态方法(1)快。而且界面一点也不慢!(我希望界面至少慢 2 倍)。

由于此结果来自受信任的来源,我想知道如何解释上述发现。

我不认为这篇文章过时是个问题,因为文章本身并没有说明任何关于阅读的内容。它所做的只是提供了一个基准测试工具。

4

2 回答 2

5

我猜想他的例子中使用的基准测试方法是有缺陷的。以下代码在 LINQPad 中运行,显示了您的预期:

/* This is a benchmarking template I use in LINQPad when I want to do a
 * quick performance test. Just give it a couple of actions to test and
 * it will give you a pretty good idea of how long they take compared
 * to one another. It's not perfect: You can expect a 3% error margin
 * under ideal circumstances. But if you're not going to improve
 * performance by more than 3%, you probably don't care anyway.*/
void Main()
{
    // Enter setup code here
    var foo = new Foo();
    var actions = new[]
    {
        new TimedAction("control", () =>
        {
            // do nothing
        }),
        new TimedAction("non-virtual instance", () =>
        {
            foo.DoSomething();
        }),
        new TimedAction("virtual instance", () =>
        {
            foo.DoSomethingVirtual();
        }),
        new TimedAction("static", () =>
        {
            Foo.DoSomethingStatic();
        }),
    };
    const int TimesToRun = 10000000; // Tweak this as necessary
    TimeActions(TimesToRun, actions);
}

public class Foo
{
    public void DoSomething() {}
    public virtual void DoSomethingVirtual() {}
    public static void DoSomethingStatic() {}
}


#region timer helper methods
// Define other methods and classes here
public void TimeActions(int iterations, params TimedAction[] actions)
{
    Stopwatch s = new Stopwatch();
    int length = actions.Length;
    var results = new ActionResult[actions.Length];
    // Perform the actions in their initial order.
    for(int i = 0; i < length; i++)
    {
        var action = actions[i];
        var result = results[i] = new ActionResult{Message = action.Message};
        // Do a dry run to get things ramped up/cached
        result.DryRun1 = s.Time(action.Action, 10);
        result.FullRun1 = s.Time(action.Action, iterations);
    }
    // Perform the actions in reverse order.
    for(int i = length - 1; i >= 0; i--)
    {
        var action = actions[i];
        var result = results[i];
        // Do a dry run to get things ramped up/cached
        result.DryRun2 = s.Time(action.Action, 10);
        result.FullRun2 = s.Time(action.Action, iterations);
    }
    results.Dump();
}

public class ActionResult
{
    public string Message {get;set;}
    public double DryRun1 {get;set;}
    public double DryRun2 {get;set;}
    public double FullRun1 {get;set;}
    public double FullRun2 {get;set;}
}

public class TimedAction
{
    public TimedAction(string message, Action action)
    {
        Message = message;
        Action = action;
    }
    public string Message {get;private set;}
    public Action Action {get;private set;}
}

public static class StopwatchExtensions
{
    public static double Time(this Stopwatch sw, Action action, int iterations)
    {
        sw.Restart();
        for (int i = 0; i < iterations; i++)
        {
            action();
        }
        sw.Stop();

        return sw.Elapsed.TotalMilliseconds;
    }
}
#endregion

结果:

                       DryRun1 DryRun2  FullRun1 FullRun2
 control               0.0361  0        47.82    47.1971 
 non-virtual instance  0.0858  0.0004   69.6178  68.7508 
 virtual instance      0.1676  0.0004   70.5103  69.2135 
 static                0.1138  0        66.6182  67.0308 

结论

这些结果表明,与常规实例方法调用相比,对虚拟实例的方法调用仅比静态调用稍长一点(在考虑控制因素后可能会增加 2-3%)这就是我所期望的。

更新

在@colinfang 评论了[MethodImpl(MethodImplOptions.NoInlining)]在我的方法中添加属性之后,我做了更多的尝试,我只能得出结论,微优化很复杂。以下是一些观察:

  • 正如@colinfang 所说,在方法中添加 NoInlining 确实会产生更像他所描述的结果。毫不奇怪,方法内联是系统可以优化非虚拟方法以比虚拟方法运行得更快的一种方式。但令人惊讶的是,不内联实际上会使虚拟方法比非虚拟方法花费更长的时间。
  • 如果我用 编译/optimize+,非虚拟实例调用实际上比控件花费的时间少 20% 以上。
  • 如果我消除 lambda 函数,并像这样直接传递方法组:

    new TimedAction("non-virtual instance", foo.DoSomething),
    new TimedAction("virtual instance", foo.DoSomethingVirtual),
    new TimedAction("static", Foo.DoSomethingStatic),
    

    ...然后虚拟和非虚拟调用最终花费的时间大致相同,但静态方法调用花费的时间要长得多(超过 20%)。

所以,是的,奇怪的东西。关键是:当你深入到这个优化级别时,由于编译器、JIT 甚至硬件级别的任意数量的优化,都会出现意想不到的结果。我们看到的差异可能是由于 CPU 的 L2 缓存策略等无法控制的结果。这里是龙。

于 2013-05-07T15:08:16.567 回答
0

反直觉的结果可能出现的原因有很多。一个原因是虚拟调用有时(可能大部分时间)会发出callvirtIL 指令,以确保进行空检查(可能在搜索 vtable 时)。另一方面,如果 JIT 可以确定只有一个特定的实现将在虚拟调用点(以及非空引用)被调用,它很可能会尝试将其转换为静态调用。

我认为这是在您的应用程序设计中真正不重要的少数事情之一。您应该考虑虚拟/密封一种语言结构,而不是运行时结构(让运行时做它最擅长的事情)。如果某个方法需要为您的应用程序的需要是虚拟的,则将其设为虚拟。如果它不需要是虚拟的,请不要制作它。而且,如果您确实打算将设计基于您的应用程序,那么就没有必要对其进行基准测试。(好奇心除外。)

于 2013-05-07T15:24:32.230 回答