我最相关的经验是编写代码来比较大型对象模型中相同类型的任何两个数据实体的属性。把它修好，试了试，显然跑得像条狗。

我很沮丧，然后在一夜之间意识到，在不改变逻辑的情况下，我可以使用相同的算法自动生成方法来进行比较，但静态地访问属性。为了这个目的调整代码完全不花时间，而且我有能力对实体与静态代码进行深入的属性比较，每当对象模型发生变化时，只要单击按钮就可以更新静态代码。

我的观点是:在与同事的对话中，因为我已经多次指出他们使用反射可以自动生成代码来编译，而不是执行运行时操作，这通常值得考虑。

如果将反射用于频繁创建对象，则它会对性能产生显著影响。我开发了一个基于复合UI应用程序块的应用程序，它严重依赖反射。通过反射创建对象时，有明显的性能下降。

但是在大多数情况下，使用反射是没有问题的。如果你只需要检查一些组装，我会推荐Mono。塞西尔，非常轻，速度很快

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

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

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.

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

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

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

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

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

和所有事情一样，这都是关于评估形势。在DotNetNuke中，有一个相当核心的组件叫做FillObject，它使用反射从数据箭头填充对象。

这是一个相当常见的场景，在MSDN上有一篇文章，使用反射将业务对象绑定到ASP。NET表单控件，涵盖了性能问题。

除了性能之外，我不喜欢在这种特定情况下使用反射的一件事是，它往往会降低快速理解代码的能力，对我来说，当你考虑到与强类型数据集或类似LINQ to SQL的数据集相比，你还失去了编译时的安全性，这似乎不值得付出努力。