.NET异常有多慢？

Question

.NET异常有多慢？

我不想讨论什么时候要和不要抛出异常。我想解决一个简单的问题。99%的情况下，不抛出异常的争论围绕着它们是缓慢的，而另一方则声称(通过基准测试)速度不是问题。我读过许多博客，文章，以及关于一方或另一方的文章。那是哪一个？

Answer 1

我站在“不慢”的一边-或者更确切地说，“不够慢，不值得在正常使用中避开它们”。我写了两个矮的 文章关于这件事。对于基准测试方面有一些批评，主要是因为“在现实生活中会有更多的堆栈需要通过，所以您会销毁缓存等”-但是使用错误代码在堆栈上工作也打开缓存，所以我不认为这是一个特别好的论点。我不支持在不符合逻辑的情况下使用异常。例如,int.TryParse完全适合于从用户转换数据。当读取机器生成的文件时，这是适当的，因为失败意味着“文件没有按其应有的格式，我真的不想尝试处理这个问题，因为我不知道还有什么问题。”当在“只有合理的情况下”使用异常时，我从未见过有一个应用程序的性能受到异常的严重损害。基本上，除非您有重大的正确性问题，否则异常不应该经常发生，如果您有重大的正确性问题，那么性能不是您面临的最大问题。

Answer 2

(警告2-它写得很好，如果你是一个技术人员，你会读到最后，然后必须弥补你的工作时间：)执行摘要：进展缓慢。它们被实现为Win 32 SEH异常，因此有些甚至会通过环形0 CPU边界！显然，在现实世界中，你会做很多其他的工作，所以奇怪的例外将不会被注意到，但如果你使用他们的程序流，除了你的应用程序被锤击。这是MS营销机器对我们不利的又一个例子。我记得有一个Microsoftie告诉我们，他们是如何产生绝对零开销的，这完全是乱七八糟的。克里斯引用了一句中肯的话：事实上，即使在引擎的非托管部分，CLR也在内部使用异常。但是，除了例外情况外，还有一个严重的长期性能问题，这必须在您的决定中考虑到。