委托非常快，虽然不如直接方法调用快，但也相差不远。它们成为瓶颈的几率微乎其微。

同样，异常如果被正确使用，很少会导致性能问题。

使用委派会使你的代码更简单、更易读和更健壮吗？如果是这样，就使用它们。仔细衡量你的表现，并保持关注。只有当数据清晰时，才为了表现而远离可读性。

我确定有一些图表显示委托、接口和非虚方法调用等的速度-我不知道它们在哪里，但如果你真的担心的话，你可以自己运行测试。

仅对Jon的帖子做一个小补充：当以正常的C#方式使用（即通过lambda表达式/匿名方法/事件处理程序等），它们绝对非常快 - 但请注意，另一个重要的委托使用方式是执行动态代码（在运行时构建的方法或通过反射和Delegate.CreateDelegate执行现有方法）。当以这种第二种方式使用时，委托提供非常显著的速度改善（与反射Invoke等相比）。

所以不要害羞地使用委托。特别是，如果有疑问-测量它是否为现实代码：如果仍然仅占总执行时间的0.01％，那么它是否需要1只微型黄鼠狼还是100只微型黄鼠狼都没有意义。

*=只是一点点微不足道的时间...

我在Windows CE上工作，所以这种事情有时会更加重要。例如，不恰当地使用反射会对应用程序造成严重损害，因此我们倾向于在合理的情况下避免使用反射（显然，反射的一些小应用是没有问题的）。显然，我在桌面上不会做这样的疯狂行为。

我听到人们在私下议论代表和CE性能，但就我个人而言，它们是完全无意义的。我听说它会“减缓方法调用速度30%”，但如果它是基于一个糟糕的算法，那么这是谁的错？CE中的另一个减速因素是虚方法，因为没有查找表，所以它首先手动计算并缓存结果。这意味着，如果你浪费所有内存，那么这些缓存将被清除，并且下一次的性能会受到影响。但是，考虑到这一点，你应该为了性能而放弃有用的面向对象编程技能吗？

我发现很多“哦我的神啊，不要用那个，它太慢了”的话只是借口。主要是借口，因为人们不知道他们的应用程序的真正问题在哪里，而且很容易责怪CLR的一些内部工作，而不是他们自己的代码。如果你的性能很差，那么我想99.9%的时间你可以在你的应用程序或设计的一部分中改变一些东西，而不是扔掉工具，从而获得更好的改进。

当涉及编程时，性能可能是一个敏感的话题。例如，有些人绝对坚信框架算法是万恶之源。其他人认为字符串连接会对性能产生很大的影响。

实际上，一切都是相对的，关键取决于你所谈论的上下文。如果您在移动设备上编程，那么您将比在桌面应用程序上工作时更想要进行优化。

通常情况下，这涉及到在性能和代码优雅之间进行权衡。 假设您制作了世界上最结构化、可维护和易理解的代码库。 但是一旦我们引入性能优化，我们就会用一些可能与逻辑相悖、非常专业化的东西来使代码变得复杂。如果我们对其进行优化，我们可能会得到5％或10％的性能优化，但在过程中完全破坏了代码的优雅。

这个问题是“值得吗？”。

如果性能对你的项目绝对至关重要，那就在你的代码上运行分析器。如果你发现有一个特别低效的方法占用了90%的处理器时间，那么这个方法就是优化的好候选。通常情况下，追求低性能收益没有价值，除非你正在处理一个性能至关重要的应用程序。