.NET反射的成本有多高？

Question

我经常听到使用反射有多糟糕。虽然我通常会避免反思，很少会发现没有反思就不可能解决问题的情况，但我想知道……

对于那些在应用程序中使用反射的人，你有没有测量过性能影响，它真的那么糟糕吗？

Answer 1

它是。但这取决于你想要做什么。

我使用反射来动态加载程序集(插件)，并且它的性能“惩罚”不是问题，因为操作是我在应用程序启动时执行的操作。

但是，如果您在一系列嵌套循环中进行反射，并在每个循环上进行反射调用，我建议您应该重新访问您的代码:)

对于“几次”操作，反射是完全可以接受的，您不会注意到它有任何延迟或问题。这是一个非常强大的机制，甚至被.NET使用，所以我不明白你为什么不试一试。

Answer 2

在他的talk The Performance of Everyday Things中，Jeff Richter展示了通过反射调用一个方法大约比正常调用慢1000倍的。

杰夫的提示:如果需要多次调用该方法，请使用反射一次找到它，然后将其分配给一个委托，然后调用该委托。

Answer 3

反射性能将取决于实现(重复调用应该被缓存，例如：entity.GetType().GetProperty("PropName"))。由于我每天看到的大多数反射都是用来填充来自数据读取器或其他存储库类型结构的实体，所以我决定特别针对用于获取或设置对象属性的反射进行性能基准测试。

我设计了一个测试，我认为这是公平的，因为它缓存了所有重复的调用，并且只计算实际的SetValue或GetValue调用的时间。性能测试的所有源代码都在https://bitbucket.org/grenade/accessortest的bitbucket中。审查是受欢迎和鼓励的。

我得出的结论是，删除数据访问层中的反射是不实用的，并且在反射实现良好的情况下一次返回少于100,000行的数据访问层中的反射不会提供明显的性能改进。

​

​

上面的图表展示了我的小基准测试的输出，并显示了性能优于反射的机制，只有在100,000个周期标记之后才能明显做到这一点。大多数DAL一次只返回几百甚至数千行，在这些级别上，反射执行得很好。