只有if-else,try-catch是否比失败更快?

时间:2018-04-20 13:16:58

标签: javascript performance-testing

我的情况是我有一个小的javascript程序在大量数据上运行,格式化为2维数组。对于每个循环,它循环遍历数据,在进行计算之前调用序列化程序方法来序列化该记录。每个周期的数据都是相同的。所以现在我想将序列化数据缓存到另一个数组中,以便从第二次开始就不必再次调用序列化器。

这是我的功能:

  var cached=[];
  function getRow(x,y){
    if(!cached[x]){
      cached[x] = [];
    }
    if(!cached[x][y]){
      cached[x][y] = serializer(data,x,y);
    }
    return cached[x][y] ;
  }

到目前为止它的确有效。但正如您所看到的,对于每一行,它必须在返回缓存数据之前检查2个条件,并且条件仅在第一个循环中有用。所以我正在考虑使用try-catch而不是if-else来处理它。因此,在第一个周期中,try块将一直失败,然后我将填充catch块中的缓存。然后在第一个循环之后,当所有数据都被缓存时,它将正确地获取值并返回它。

但我担心的是:通过这样做会更快或者try-catch会降低功能和性能吗?

1 个答案:

答案 0 :(得分:2)

try/catch只会在没有引发错误的情况下更有效。而且,让我们清楚,对于现代客户来说,效率的提高将是微不足道的,并且在大多数应用中可能并不明显。

当抛出错误时,性能将受到影响,因为实例化并配置了错误对象,为该错误对象创建了一个范围,并且(当然)JS运行时必须从错误中恢复。

根据我的经验,try/catch通常首先使用不正确。它不应该是"选择"使用try/catch,这应该是一个问题或必要性。如果您的代码有可能导致错误并且有一种方法可以对其进行编码以避免该错误,那么执行此操作 - 不需要try/catch

示例:

  • 应该处理因用户输入错误而可能发生的错误 通过重新思考UI以及如何处理输入。
  • 由于与远程交互不良而可能发生的错误 source(想想AJAX)通常有错误和超时回调 选项。

如果您的代码有一种方法可以抛出错误而且它无法控制您的代码(网络中断,服务器错误),则可能需要try/catch 。我说可能因为现在很多API都有错误回调函数来处理这些事情。

简而言之,您不应该只选择try/catchtry/catch是在没有其他解决方案可用时使用的语言功能。