捕获异常时真的会影响性能吗？

Question

我问了一个关于exceptions 的问题，我对有人说投掷速度很慢感到非常恼火。我过去问过How exceptions work behind the scenes，我知道在正常的代码路径中没有额外的指令（正如公认的答案所说），但我并不完全相信投掷比检查返回值更昂贵。考虑以下几点：

{
    int ret = func();
    if (ret == 1)
        return;
    if (ret == 2)
        return;
    doSomething();
}

对

{
    try{
        func();
        doSomething();
    }
    catch (SpecificException1 e)
    {
    }
    catch (SpecificException2 e)
    {
    }
}

据我所知，除了 ifs 被移出正常代码路径进入异常路径和额外的一两次跳转到异常代码路径之外，没有什么区别。当它减少你的主要和更经常运行的代码路径中的几个ifs 时，额外的一两次跳转听起来并不多。那么异常真的很慢吗？或者这是一个神话或旧编译器的旧问题？

（我说的是一般性的异常。具体来说，是 C++ 和 D 等编译语言中的异常；尽管 C# 也在我的脑海中。）

Answer 1

好的 - 我刚刚运行了一个小测试以确保异常实际上更慢。摘要：在我的机器上，每次迭代调用 w/return 是 30 个周期。每次迭代的 throw w/catch 是 20370 个周期。

所以要回答这个问题 - 是的 - 抛出异常很慢。

这是测试代码：

#include <stdio.h>
#include <intrin.h>

int Test1()
{
    throw 1;
//  return 1;
}


int main(int argc, char*argv[])
{
    int result = 0;
    __int64 time = 0xFFFFFFFF;
    for(int i=0; i<10000; i++)
    {
        __int64 start = __rdtsc();
        try
        {
            result += Test1();
        }
        catch(int x)
        {
            result += x;
        }
        __int64 end = __rdtsc();
        if(time > end - start)
            time = end - start;
    }

    printf("%d\n", result);
    printf("time: %I64d\n", time);
}

由 op 编写的替代 try/catch

try
{
        if(Test1()!=0)
                result++;
}
catch(int x)
{
        result++;

Answer 2

我不知道它到底有多慢，但是抛出一个已经存在的异常（比如它是由 CLR 创建的）并不会慢很多，因为你已经遭受了构造异常的影响。 ...我相信是异常的构造造成了大部分额外的性能损失...想想看，它必须创建一个堆栈跟踪，（包括读取调试符号以添加行号和内容）并可能捆绑内部异常等。

实际上抛出异常只会添加额外的代码来遍历堆栈以找到适当的 catch 子句（如果存在）或将控制权转移到 CLR 未处理的异常处理程序......这部分对于非常深的堆栈来说可能是昂贵的, 但是如果 catch 块就在你扔它的方法的底部，例如，那么它会相对便宜。

Answer 3

如果您使用异常来实际控制流程，它可能会大受欢迎。

我正在挖掘一些旧代码，看看为什么它运行得这么慢。在一个大循环中，它不是检查 null 并执行不同的操作，而是捕获 null 异常并执行替代操作。

因此，不要将异常用于它们原本不打算做的事情，因为它们速度较慢。

Answer 4

使用异常和一般任何东西，而不用担心性能。然后，完成后，使用分析工具测量性能。如果不能接受，你可以找到瓶颈（可能不是异常处理）并优化。

Answer 5

在 C# 中，引发异常确实会对性能造成非常轻微的影响，但这不应该让您害怕使用它们。如果你有原因，你应该抛出一个异常。大多数使用它们有问题的人都说原因是因为它们会破坏程序的流程。

真的，如果您不使用它们的原因是性能受到影响，那么您可以更好地花时间优化代码的其他部分。我从来没有遇到过抛出异常导致程序运行缓慢以至于必须重新分解它的情况（抛出异常的行为，而不是代码如何处理它）。

再想一想，话虽如此，我确实尝试使用避免抛出异常的方法。如果可能的话，我会使用 TryParse 而不是 Parse，或者使用 KeyExists 等。如果您执行相同的操作 100 次以上并抛出许多异常，则可能会增加少量的低效率。

Answer 6

是的。异常会使您的程序在 C++ 中变慢。不久前我创建了一个 8086 CPU 模拟器。在代码中，我使用了 CPU 中断和故障的异常。我做了一个大的复杂循环的小测试用例，运行了大约 2 分钟的模拟操作码。当我通过分析器运行此测试时，我的主循环正在对 gcc 的“异常检查器”函数进行大量调用（实际上有两个不同的函数与此相关。但是我的测试代码最后只抛出了一个异常.) 我相信每次都在我的主循环中调用这些异常函数（这是我有 try{}catch{} 部分的地方。）。异常函数花费了我大约 20% 的运行时速度。（代码在那里花费了 20% 的时间）。异常函数也是分析器中调用次数最多的第 3 和第 4 函数...

所以是的，即使没有持续抛出异常，使用异常也会很昂贵。

Answer 7

tl;dr 恕我直言，出于性能原因避免异常会影响过早优化和微优化这两个类别。不要这样做。

啊，例外的宗教战争。

对此的各种类型的答案通常是：

• 通常的口头禅（很好，恕我直言）：“在异常情况下使用异常”（IOW，不是“正常”代码路径的一部分）。
  • 如果您的正常用户路径涉及故意使用异常作为控制流机制，那就太难了。
• 大量细节，没有真正回答原始问题
  • 如果你真的想要细节：
  • http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx
  • http://blogs.msdn.com/ricom/archive/2006/09/14/754661.aspx
  • 等
• 有人指着微基准测试表明，像 i/j 这样 j == 0 的东西，捕捉 div-by-zero 比检查 j == 0 慢 10 倍
• 关于如何处理一般应用程序性能的实用答案
  • 通常是这样的：
  • 为您的场景制定性能目标（最好与客户合作）
  • 构建它，使其可维护、可读且健壮
  • 运行它并检查目标场景的性能
  • 如果一组场景没有达到目标，请使用 PROFILER 告诉您您的时间都花在了哪里，然后从那里开始。
  • IOW，任何性能更改，尤其是像这样的微优化，在没有分析数据驱动该决策的情况下进行，通常都是浪费时间。

请记住，您的性能获胜通常来自算法更改（向表添加索引以避免表扫描，将具有较大 n 的内容从 O(n^3) 移动到 O(n ln n) 等。 )。

更多有趣的链接：

• http://en.wikipedia.org/wiki/Program_optimization
• http://www.flounder.com/optimization.htm

Answer 8

如果您想知道异常在 Windows SEH 中是如何工作的，那么我相信this article by Matt Pietrik 被认为是权威参考。这不是轻读。如果您想将此扩展到异常在 .NET 中的工作方式，则需要阅读 this article by Chris Brumme，这绝对是权威参考。读起来也不轻松。

Chris Brumme 文章的摘要详细解释了为什么异常比使用返回码慢得多。在这里复现太长了，在完全理解原因之前，您需要阅读大量内容。

Answer 9

部分答案是编译器并没有非常努力地优化异常代码路径。

• catch 块是对编译器以牺牲异常代码路径为代价积极优化非异常代码路径的一个非常强烈的提示。为了可靠地提示编译器 if 语句的哪个分支是例外分支，您需要配置文件引导优化。

• 异常对象必须存储在某个地方，并且因为抛出异常意味着堆栈展开，所以它不能在堆栈上。编译器知道异常很少见——因此优化器不会做任何可能减慢正常执行的事情——比如保持寄存器或任何类型的“快速”内存可用，以防它需要将异常放入其中。您可能会发现出现页面错误。相反，返回码通常以寄存器结束（例如 EAX）。

Answer 10

这就像连接字符串与字符串生成器。如果你做十亿次，它只会很慢。