82

当其中任何一个都没有引发异常时，使用多个 try-catch 块是否“慢”？我的问题和这个问题一样，但是是针对 JavaScript 的。

假设我有 20 个函数，其中包含 try-catch 块，另一个函数调用这 20 个函数中的每一个，其中没有一个抛出异常。我的代码会因为这个 try-catch 块而执行得更慢或更差吗？

4

4 回答 4

70

你在做典型的 CRUD UI 代码吗？使用尝试捕获，使用无缘无故地在代码中散布到 10000 的循环，地狱，使用 angular/ember - 你不会注意到任何性能问题。

如果您正在做低级库、物理模拟、游戏、服务器端等，那么从不抛出 try-catch 块通常根本不重要，但问题是 V8 在其优化编译器中直到版本 6 才支持它引擎，因此语法上包含 try catch 的整个包含函数将不会被优化。不过，您可以通过创建如下辅助函数轻松解决此问题tryCatch：

function tryCatch(fun) {
    try {
        return fun();
    }
    catch(e) {
        tryCatch.errorObj.e = e;
        return tryCatch.errorObj;
    }
}
tryCatch.errorObj = {e: null};


var result = tryCatch(someFunctionThatCouldThrow);
if(result === tryCatch.errorObj) {
    //The function threw
    var e = result.e;
}
else {
    //result is the returned value
}

在 V8 版本 6（附带 Node 8.3 和最新的 Chrome）之后，内部代码的性能与try-catch普通代码相同。

于 2013-11-01T14:34:43.537 回答
53

最初的问题询问了未引发错误时 try/catch 的成本。使用 try/catch 保护代码块时肯定会产生影响，但是随着被保护的代码变得稍微复杂一些，try/catch 的影响会很快消失。

考虑这个测试：http: //jsperf.com/try-catch-performance-jls/2

一个简单的增量每秒运行 356,800,000 次迭代。 try/catch 中的相同增量是每秒 93,500,000 次迭代。由于 try/catch，开销为 75%。但是，一个微不足道的函数调用每秒运行 112,200,000 次迭代。2 个微不足道的函数调用以每秒 61,300,000 次迭代运行。

在这个测试中，未执行的尝试比一个简单的函数调用花费的时间略多。除了像 FFT 这样非常激烈的东西的最内层循环之外，这几乎不是一个重要的速度损失。

您要避免的情况是实际抛出异常的情况。如上面的链接所示，这非常慢。

编辑：这些数字适用于我机器上的 Chrome。在 Firefox 中，未执行的尝试和完全没有保护之间没有显着差异。如果没有抛出异常，使用 try/catch 基本上是零惩罚。

于 2015-12-27T22:33:00.333 回答
8

try-catch据说这个街区很贵。但是，如果关键性能不是问题，则使用它不一定是一个问题。

国际海事组织的处罚是：

  • 可读性
  • 在许多情况下不合适
  • 在异步编程方面无效

可读性：用大量的 try-catch 来检查你的代码是丑陋和分散注意力的

不恰当：如果您的代码不受异常崩溃的影响，那么插入这样的块是个坏主意。仅当您预计代码失败时才插入它。查看以下主题：何时使用 try/catch 块？

Async：块是同步的，在编程try-catch时无效。async在ajax请求期间，您可以在专用回调中同时处理error和success事件。不需要try-catch。

希望这可以帮助，

R。

于 2013-11-01T14:05:32.133 回答
7

我试图根据具体的基准测试结果提供答案。为此，我编写了一个简单的基准测试，将 try-catch 与从简单到更复杂的各种 if-else 条件进行比较。我知道基准可能会根据平台而发生很大变化。如果您得到不同的结果，请发表评论。请参阅此处的 try-catch 基准测试。

首先，我尝试在此处以紧凑的方式表示测试套件。有关完整详细信息，请参阅上面的链接。有四个测试用例，后面用 (index) 引用：

  • (1) try-catch 块，它调用lib.foo带有一点三角数学的函数。不会抛出任何错误。
  • (2) if-else 块通过检查函数是否存在'foo' in lib然后调用该函数。
  • (3) if-else 块通过检查函数是否存在typeof lib['foo'] === 'function'然后调用该函数。
  • (4) if-else 块通过检查函数是否存在Object.prototype.hasOwnProperty.call(lib, 'foo')然后调用该函数。

我在 Chrome 87 上跑了几次 benchmark。虽然实际数字不时变化，但结果是一致的，大致可以总结如下：

  • try-catch (1) 和 if-else (2) 在运行时几乎是等价的。try-catch (2) 有时会慢 1% 到 2%。
  • if-else (3) 比 try-catch (1) 或 if-else (2) 慢 75%。
  • if-else (4) 比 try-catch (1) 或 if-else (2) 慢 90%。

澄清一下，慢 75% 意味着如果最快的情况需要 1.0 秒，那么慢 75% 的执行需要 1.75 秒。

作为结论，在从不抛出错误的情况下使用 try-catch 似乎与检查任何简单条件一样有效。如果条件有更复杂的情况，try-catch 会明显更快。

作为个人笔记，结论与我在大学所教的内容一致。尽管它是在 C++ 的上下文中，但同样的教训似乎也适用于此。如果我没记错的话，我的讲师说 try-block 被设计为非常高效，几乎看不见效率。然而，这是一个很慢的捕获块，我的意思是真的很慢。如果抛出错误，那么使用 catch-block 进行的处理比使用 if-else 块所花费的时间长数百甚至数千倍。因此，保持你的异常例外。

于 2021-01-04T21:31:26.177 回答