您甚至不得不担心. net库内部为性能关键型代码所做的反射，这已经够糟糕的了。

下面的例子在当时(2008年)是过时的，但在最近的CLR版本中早就修复了。不过，总的来说，反思仍然是一件有点昂贵的事情!

举个例子:在高性能代码中，永远不要在lock (c#) / SyncLock (VB.NET)语句中使用声明为“Object”的成员。为什么?因为CLR不能锁定值类型，这意味着它必须执行运行时反射类型检查，以查看您的对象是否实际上是值类型而不是引用类型。

As with all things in programming you have to balance performance cost with with any benefit gained. Reflection is an invaluable tool when used with care. I created a O/R mapping library in C# which used reflection to do the bindings. This worked fantastically well. Most of the reflection code was only executed once, so any performance hit was quite small, but the benefits were great. If I were writing a new fandangled sorting algorithm, I would probably not use reflection, since it would probably scale poorly.

很抱歉，我还没有完全回答你的问题。我的观点是，这并不重要。在适当的地方使用反射。它只是你需要学习如何以及何时使用的另一种语言功能。

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

我使用反射动态加载程序集(插件)，它的性能“惩罚”不是问题，因为操作是我在应用程序启动期间所做的事情。

然而，如果你在一系列嵌套循环中反射，每个循环都有反射调用，我想说你应该重新审视你的代码:)

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

反射的代价很高，因为每当您请求与参数列表匹配的方法时，运行时必须进行许多检查。在内部的某个深处，存在一些代码，它们循环遍历一个类型的所有方法，验证其可见性，检查返回类型，并检查每个参数的类型。所有这些都需要时间。

当你在内部执行这个方法时，有一些代码会在执行实际的目标方法之前检查你传递了一个兼容的参数列表。

如果可能，总是建议缓存方法句柄，如果将来要不断地重用它。像所有好的编程技巧一样，避免重复通常是有意义的。在这种情况下，不断地查找具有特定参数的方法，然后每次都执行它将是一种浪费。

戳一下源代码，看看正在做什么。

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

Jeff的建议:如果需要多次调用该方法，请使用一次反射来找到它，然后将其分配给委托，然后调用委托。

反射不会大幅降低应用程序的性能。不使用反射可能会更快地完成某些事情，但如果反射是实现某些功能的最简单方法，那么就使用它。如果反射成为一个性能问题，你总是可以重构你的代码。