.NET反射的“成本”是多少？ [重复]

Question

可能重复：
.NET反射的成本是多少？

我目前的编程思想是反思是我最好的朋友。 我经常使用它来动态加载允许“宽松实现”而不是严格接口的内容，以及许多自定义属性。

使用反射的“实际”成本是多少？

对于经常反射的类型具有高速缓存的反射，例如在表定义的所有属性上我们自己的LINQ DAL前目标代码，是否值得付出努力？

缓存内存占用量是否会超过反射CPU的使用量？

Answer 1

反射需要加载并处理大量类型的元数据。 这会导致更大的内存开销和较慢的执行。 根据本文，属性修改的速度要慢2.5到3倍，而方法调用的速度要慢3.5到4倍。

这是一篇很棒的MSDN文章，概述了如何使反射更快以及开销在哪里。 如果您想了解更多信息，我强烈建议您阅读。

反射还会增加代码的复杂性，这会使代码更加混乱，因此很难使用。 像斯科特·汉塞尔曼（Scott Hanselman）这样的人相信，通过反思，您经常遇到的问题比您解决的更多。 如果您的团队主要是初级开发人员，则尤其如此。

如果您需要大量动态行为，则最好研究一下DLR（动态语言运行时）。 随着.NET 4.0中的新更改，您可能需要查看是否可以将其中的某些内容合并到解决方案中。 VB和C＃对动态的附加支持使动态代码的使用非常优雅，并且可以很直接地创建自己的动态对象。

祝好运。

编辑：我在斯科特（Scott）的网站上做了更多的戳记，并在反思中发现了这个播客。 我没有听过，但也许值得。

Answer 2

您可以做很多事情来加快反射速度。 例如，如果您要进行大量的属性访问，则HyperDescriptor可能会有用。

如果您要进行很多方法调用，则可以使用Delegate.CreateDelegate将方法缓存到类型化的委托中-然后，仅执行一次类型检查等操作（在CreateDelegate期间）。

如果您要进行大量的对象构造，那么Delegate.CreateDelegate将无济于事（您不能在构造函数上使用它）-但是（在3.5版中）可以使用Expression来执行此操作，然后再次编译为类型化委托。

是的：反射很慢，但是您可以优化它而不会感到太多痛苦。

Answer 3

拥有权利的同时也被赋予了重大的责任。

如您所说，反射具有相关的成本，并且取决于反射的数量会大大降低应用程序的速度。

非常适合使用它的地方之一是IoC（控制反转），因为根据您应用程序的大小，它可能会带来更多的好处。

Answer 4

感谢您提供的出色链接和好评，尤其是对于Jr Devs而言，这笔钱是正确的。

对于我们来说，初级开发人员更容易做到这一点：

[TableName("Table")]
public class SomeDal : BaseDal
{
    [FieldName("Field")]
    public string Field
}

而不是DAL的一些更大的实现。 这加快了DAL对象的构建速度，同时隐藏了所有内部工作，供高级开发人员使用。

糟糕的是LINQ没来得及，我有时有时只写了一半。

Answer 5

在使用反射时有时会咬人的一件事是在重构时不使用反射来更新调用。 诸如resharper之类的工具会在您更改方法名称时提示您更新注释和字符串，因此您可以通过这种方式捕获大多数注释，但是在调用动态生成的方法或动态生成的方法名称时，您可能会想念的东西。

唯一的解决方案是好的文档编制和彻底的单元测试。