为什么使用 `Delegate.CreateDelegate` 创建的委托比 lambda 和方法委托更快？答案

【问题标题】：Why is Delegate created with `Delegate.CreateDelegate` faster than lambda and method delegates?为什么使用 `Delegate.CreateDelegate` 创建的委托比 lambda 和方法委托更快？
【发布时间】：2018-05-16 18:22:40
【问题描述】：

一直以来，我一直在阅读有关反射的文章，每个人都在说：“反射很慢”，“反射很慢”。

现在我决定测试一下有多慢，令我惊讶的是，使用反射创建的委托实际上大约是使用 lambda 创建的委托的两倍，而且令人惊讶的是，它比采用声明方法的委托快四倍。

查看代码

这是一个自定义类，其属性获取方法将在委托中使用：

#class to test
class SomeClass
{
    public SomeClass A { get; set; } //property to be gotten
    public static SomeClass GetA(SomeClass c) { return c.A; } //declared getter method
}

这是我测试的三个代表：

PropertyInfo AProp = typeof(SomeClass).GetProperty("A");

//1 - Created with reflection
Func<SomeClass, SomeClass> Getter = (Func<SomeClass, SomeClass>)Delegate.CreateDelegate(typeof(Func<SomeClass, SomeClass>), null, AProp.GetGetMethod());

//2 - Created with a lambda expression
Func<SomeClass, SomeClass> Getter2 = c => c.A;

//3 - Created from a declared method
Func<SomeClass, SomeClass> Getter3 = SomeClass.GetA;

这些是测试：

SomeClass C = new SomeClass();
C.A = new SomeClass(); //test doesn't change whether A is set or null
Stopwatch w;

//reflection delegate
w = Stopwatch.StartNew();
for (int i = 0; i < 10000000; i++) { SomeClass b = Getter(C); }
w.Stop(); Console.WriteLine(w.Elapsed);

//lambda delegate
w = Stopwatch.StartNew();
for (int i = 0; i < 10000000; i++) { SomeClass b = Getter2(C); }
w.Stop(); Console.WriteLine(w.Elapsed);

//method delegate
w = Stopwatch.StartNew();
for (int i = 0; i < 10000000; i++) { SomeClass b = Getter3(C); }
w.Stop(); Console.WriteLine(w.Elapsed);

//no delegate
w = Stopwatch.StartNew();
for (int i = 0; i < 10000000; i++) { SomeClass b = C.A; }
w.Stop(); Console.WriteLine(w.Elapsed);

结果：

我还尝试颠倒测试顺序，看看是否有影响，或者手表是否以某种方式欺骗了我，但没有，测试是一致的。

编辑：按照建议考虑“发布”编译：

现在...我原以为 lambda 会更慢

【问题讨论】：

在发布模式下编译时，lambda 和反射性能之间没有太大区别，但在调试模式下，我确实看到了与您类似的输出。
......当然......我没有想到。如果您愿意，可以将其发布为答案。
我实际上无法说出原因是什么，错误在哪里，但这是我的results 使用BenchmarkDotNet 库制作的代码。基准测试肯定很难。
为了进行这种基准测试，我建议您使用 BenchMarkDotNet，它可以让您更深入地了解您看到这种行为的原因，例如分配、内存使用、GC 暂停等@ 987654325@
你见过这个吗？ vibrantcode.com/2013/02/19/lambdas-vs-method-groups

标签： c# performance reflection lambda delegates

【解决方案1】：

这是它的反编译：

    Func<SomeClass, SomeClass> Getter = (Func<SomeClass, SomeClass>)Delegate.CreateDelegate(typeof(Func<SomeClass, SomeClass>), null, AProp.GetGetMethod());
    Func<SomeClass, SomeClass> arg_51_0;
    if ((arg_51_0 = Program.<>c.<>9__12_0) == null)
    {
        arg_51_0 = (Program.<>c.<>9__12_0 = new Func<SomeClass, SomeClass>(Program.<>c.<>9.<Main>b__12_0));
    }
    Func<SomeClass, SomeClass> Getter2 = arg_51_0;
    Func<SomeClass, SomeClass> Getter3 = new Func<SomeClass, SomeClass>(SomeClass.GetA);

注意第一个在编译器中几乎没有变化，而第二个和第三个被大量修改。

如果我不得不冒险猜测：

第一个调用是利用 Delegate 库中使用的某种偷偷摸摸的内存管理 C++/COM 技巧。

第二个是创建一个新方法并在调用它的新方法之前添加一个空检查。

虽然第三个正在做与第二个类似的事情，但将其保存到运行时，这是我猜测为什么仍然在新的内联方法中调用属性（我本来希望将其放入自己的编译器中） created 方法，类似于第二个版本，所以我猜这部分会在编译时发生，这可以解释为什么它的时间比前两个高得多）。

我认为反射慢的 cmets 更针对大型库；我猜你在这里看不到它，因为课堂上的反映非常小，所以没有太多需要反思的地方。

编辑：当我输入最后一点时，我决定尝试通过扩展 SomeClass 对象来减慢第一次调用的速度。我添加了大约 30 个新属性和 20 个左右的新方法。似乎没有什么不同。我也听过所有关于反思的警告，所以这有点令人惊讶。 This 帖子指出，所有这些都涉及到一个缓存，这可能有很大帮助。如果所有方法元数据都被缓存，那么反射应该比通过编译器添加的额外方法和检查更快。当您反映尚未加载/缓存的外部类时，它可能会出现。不过，这是一个复杂得多的实验。

【讨论】：