try-catch阻止会降低性能吗？

Question

这个链接指出,

为了捕获异常,我们必须将一部分代码置于异常检查之下.这是通过将该部分代码包含在try块中来完成的.当在该块内出现异常情况时,抛出异常将控制转移到异常处理程序.如果没有抛出异常,代码将继续正常运行并忽略所有处理程序.

这是否意味着由于在运行时"检查"的额外任务,使用try块会降低性能？

Answer 1

TL; DR NO,与错误代码处理相比,非异常路径上的异常通常更快.

嗯,明显的评论与什么相比？

与不处理错误相比,它明显降低了性能; 但是性能是否值得缺乏正确性？我认为它不是,所以让我们假设您的意思是与使用if语句检查的错误代码进行比较.

在这种情况下,它取决于.有多种机制用于实现异常.实际上,它们可以通过一种机制来实现,这种机制非常接近于if它们最终具有相同成本(或略高)的声明.

但是在C++中,所有主要的编译器(gcc在4.x系列中引入它,MSVC将其用于64位代码)现在使用零成本异常模型.如果您阅读了Need4Sleep链接到的技术论文,则会将其列为表驱动方法.这个想法是,对于程序的每个点,可能会抛出你在边表中注册一些零碎的东西,这将允许你找到正确的catch子句.老实说,与旧策略相比,它实现起来有点复杂,但零成本名称是由于它是免费的,不应该抛出任何异常.将此与CPU上的分支错误预测进行对比.另一方面,当抛出异常时,惩罚是巨大的,因为表存储在冷区(因此可能需要往返RAM或更糟)...但异常是例外,对吧？

总而言之,使用现代C++编译器,异常比错误代码更快,代价是更大的二进制文件(由于静态表).

为了详尽无遗,还有第三种选择:堕胎.不是通过状态或异常传播错误,而是可以中止该过程.这仅适用于有限数量的情况,但它比任何一种情况都更好地优化.

Answer 2

看一下关于C++性能的技术报告草案的第5.4节, 它特别是关于c ++中try-catch语句的开销.

该部分的一些摘录:

5.4.1.1.2"规范"方法的时间开销

• On entry to each try-block
    ? Commit changes to variables enclosing the try-block
    ? Stack the execution context 
    ? Stack the associated catch clauses 
• On exit from each try-block
    ? Remove the associated catch clauses 
    ? Remove the stacked execution context 
• When calling regular functions 
    ? If a function has an exception-specification, register it for checking 
• As local and temporary objects are created 
    ? Register each one with the current exception context as it is created 
• On throw or re-throw 
    ? Locate the corresponding catch clause (if any) – this involves some runtime check (possibly resembling RTTI checks) 
    If found, then: 
    destroy the registered local objects 
    check the exception-specifications of the functions called in-between 
    use the associated execution context of the catch clause 
    Otherwise: 
    call the terminate_handler6