我经常听说使用反射是多么糟糕。虽然我通常避免反思，也很少发现不反思就无法解决问题的情况，但我在想……
对于那些在应用程序中使用反射的人，您测量过性能影响吗?它真的那么糟糕吗?
当前回答
您甚至不得不担心. net库内部为性能关键型代码所做的反射，这已经够糟糕的了。
下面的例子在当时(2008年)是过时的，但在最近的CLR版本中早就修复了。不过，总的来说，反思仍然是一件有点昂贵的事情!
举个例子:在高性能代码中，永远不要在lock (c#) / SyncLock (VB.NET)语句中使用声明为“Object”的成员。为什么?因为CLR不能锁定值类型，这意味着它必须执行运行时反射类型检查，以查看您的对象是否实际上是值类型而不是引用类型。
其他回答
我最相关的经验是编写代码来比较大型对象模型中相同类型的任何两个数据实体的属性。把它修好，试了试，显然跑得像条狗。
我很沮丧，然后在一夜之间意识到，在不改变逻辑的情况下，我可以使用相同的算法自动生成方法来进行比较，但静态地访问属性。为了这个目的调整代码完全不花时间，而且我有能力对实体与静态代码进行深入的属性比较，每当对象模型发生变化时，只要单击按钮就可以更新静态代码。
我的观点是:在与同事的对话中，因为我已经多次指出他们使用反射可以自动生成代码来编译，而不是执行运行时操作，这通常值得考虑。
您甚至不得不担心. net库内部为性能关键型代码所做的反射，这已经够糟糕的了。
下面的例子在当时(2008年)是过时的，但在最近的CLR版本中早就修复了。不过，总的来说，反思仍然是一件有点昂贵的事情!
举个例子:在高性能代码中，永远不要在lock (c#) / SyncLock (VB.NET)语句中使用声明为“Object”的成员。为什么?因为CLR不能锁定值类型，这意味着它必须执行运行时反射类型检查，以查看您的对象是否实际上是值类型而不是引用类型。
如果你不是在循环中，也不用担心。
反射不会大幅降低应用程序的性能。不使用反射可能会更快地完成某些事情，但如果反射是实现某些功能的最简单方法，那么就使用它。如果反射成为一个性能问题，你总是可以重构你的代码。
在Jeff Richter的演讲The Performance of Everyday Things中，他展示了通过反射调用一个方法要比正常调用慢1000倍。
Jeff的建议:如果需要多次调用该方法，请使用一次反射来找到它，然后将其分配给委托，然后调用委托。
