如果你不是在循环中，也不用担心。

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

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

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

我想你会发现答案是，这要看情况。如果您想把它放在任务列表应用程序中，这不是什么大问题。如果你想把它放在Facebook的持久性库中，这是一件大事。

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

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

不严重。我从来没有在桌面开发中遇到过问题，除非，正如Martin所说，你在一个愚蠢的位置使用它。我听说很多人对它在桌面开发中的表现有完全不合理的担忧。

然而，在紧凑框架(我经常参与)中，它几乎是一种诅咒，在大多数情况下应该像瘟疫一样避免。我仍然可以不经常使用它，但我必须非常小心地使用它，这就不那么有趣了。：(

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

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

我得出的结论是，在反射实现做得很好的情况下，在数据访问层中删除反射是不实际的，也不能提供明显的性能改进。

上图展示了我的小基准测试的输出，并显示了优于反射的机制，只有在100,000次循环之后才会明显表现出来。大多数dal一次只返回几百行或数千行，在这些级别反射执行得很好。