使用代表会减慢我的程序吗？
我一直在避免它们，因为我真的不知道如果它们使我的程序变慢。我知道如果我导致（catch）异常，它使用相当多的CPU功率但我不知道委托和事件以及.NET对他们做了什么。
答案 0 :(得分：17)
代表非常非常快。不如直接方法调用快，但不远。他们成为瓶颈的可能性微乎其微。
（同样，例外情况，如果使用得当，rarely actually cause a performance issue。）
使用委托会使您的代码更简单，更易读，更健壮吗？如果是这样，请使用它们。仔细衡量您的表现，并密切关注它。仅在数据清晰时才为了性能而放弃可读性。
我确信有一些图表可以显示委托与接口的速度与非虚拟方法调用等 - 我不知道它们在哪里，但如果你真的担心，你可以自己运行测试。
答案 1 :(得分：9)
只是Jon的帖子的一小部分内容：当以正常的C＃方式使用时（即通过lambdas /匿名方法/事件处理程序/等），它们肯定非常快 - 但请注意代表的另一个重要用途可以是执行动态代码（在运行时构建的方法，或通过反射和Delegate.CreateDelegate的现有方法）。当以第二种方式使用时，委托提供非常显着的速度改进（与反射Invoke等相比）。
所以不要害羞使用代表。特别是，如果有疑问 - 测量它是否真实的代码：它是否需要1或100微鼬*是没有意义的，如果这仍然只占你总执行时间的0.01％。
* =只是一些任意的时间......
答案 2 :(得分：6)
在编程方面，性能可能是一个棘手的主题。例如，有些人绝对坚持认为拳击是所有邪恶的根源。其他人认为弦乐连续剧是一个重大的表现。
实际上一切都是相对的，这一切都归结为你所谈论的背景。如果您使用移动设备进行编程，那么您将需要比在桌面应用程序上工作时更优化。
它通常归结为性能和代码优雅之间的权衡。让我们说你在世界上创造了最优秀，可维护和可理解的代码库。一旦我们抛出一些性能优化，我们就开始用一些可能反直觉，非常专业的东西来代码化云。如果我们去城镇进行优化，我们可以节省5％或10％的性能，但在这个过程中，它会破坏代码的优雅。
问题是“它值得吗？”。
如果性能对于您的项目至关重要，那么在您的代码上运行一个分析器。如果您发现90％的处理器时间被特别低效的方法吃掉，那么该方法是优化的理想选择。除非您正在开发性能关键型应用程序，否则通常不值得追求低性能优势。
答案 3 :(得分：6)
我在Windows CE上工作，所以这种事情有时候更加贴切。例如，反射的傲慢应用确实会受到伤害，因此我们倾向于避免在合理的情况下进行反射（显然反射的小应用 ）。显然我在桌面上没有这么疯狂。
我听说过人们对代表和行政长官的表现不以为然，但就我而言，我只是担心它的全部内容。我听说它“将方法调用减慢了30％”，但如果这是一个糟糕的算法的30％，那么它的错误是什么？ CE中的另一个减速是虚方法，因为没有查找表，它第一次手动处理它们并缓存结果。这意味着如果你把所有的记忆都扯掉了，那些缓存就会被清除掉，这将导致下一次打击。但是考虑到这一点，你是否应该为了表现而抛弃有用的OOP技能？
我发现很多这些“OMG不使用它太慢”只是借口。主要是借口，因为人们不知道他们的应用程序真的错误，并且很容易责怪CLR的一些内部工作而不是他们自己的代码。如果你的表现糟糕，那么我认为99.9％的时间你可以改变你的应用程序或设计中不会丢失工具并带来更好改进的部分。