在 @try 块中调用函数是否存在性能损失？答案

【问题标题】：Is there a performance penalty associated with calling a function within a @try block?在 @try 块中调用函数是否存在性能损失？
【发布时间】：2014-02-25 20:29:50
【问题描述】：

与在没有 try 块的情况下调用 blabla 相比，这会导致性能损失吗？

-(void)bla{
    @try{
        [self blabla];
    }
    @catch (NSException *e) {
        // Do nothing
    }
}

【问题讨论】：

我已经看到这里要求 C 和 C++。虽然我不肯定答案是一样的，但我敢打赌。无论如何，您应该查看这两种语言的答案中的“与什么相比”线程。例如，这是一个：stackoverflow.com/questions/16784601/…
编译器优化可能有一些小的损失，但可能没有别的。（无论如何，“Objective-C 编译器优化”有点矛盾。）
问题不大，因为我们不会在 Objective-C 中经常抛出异常 :)
@Gavin ...我们无法可靠地捕捉到它们。

标签： objective-c

【解决方案1】：

来自doc

零成本@try 块

进入零成本 @try 块的 64 位进程不会导致性能惩罚。这与 32 位的机制不同进程，它调用 setjmp() 并执行额外的“簿记”。但是，在 64 位中抛出异常要昂贵得多可执行文件。为了在 64 位中获得最佳性能，您应该抛出仅在绝对必要时例外。

所以 64 位 进程没有开销

【讨论】：

请务必注意，这仅适用于 Mac OS X。在 iOS 上，实现总是类似于 64 位 Mac 架构。

【解决方案2】：

您可能对此博客感兴趣：LLVM PROJECT BLOG

也就是说，在英特尔和 Okt 之后。 2013 年，在 ARM 上，C++ 异常现在也是“零成本”。

Objective-C 异常是根据这个实现来实现的。

但是，对展开器的需求将禁用一些优化机会，因此需要处理异常的代码的优化程度可能不如无需处理异常时的优化。

【讨论】：

【解决方案3】：

在某些平台上，@try/@catch 是“零成本”。只要没有抛出异常，就不会为 try 块执行额外的代码。异常展开数据的形式存在额外的开销，但在抛出异常之前也不会占用实际内存。这些平台包括 64 位 OS X 和 64 位 iOS。

在某些平台上，仅输入 @try 会产生一些 CPU 开销来保存寄存器。这些平台包括 32 位 OS X 和 32 位 iOS。

【讨论】：