方法链与创建不同变量对性能的影响

Performance impact of method chaining vs creating distinct variables

本文关键字：性能 影响 变量 创建 方法      更新时间：2023-09-26

给定一组用于筛选数组并对结果进行约简/求和的操作:

function arbitrary() {
  return [1,2,3].
    filter((i)=>{return i > 1}).
    reduce((prev,cur)=>{return prev+cur})
}

…我的假设是用filter的结果创建一个临时数组，并传递一个指针/引用给reduce。

如果用临时变量重写:

function arbitrary() {
  var filtered = [1,2,3].filter((i)=>{return i > 1});
  return filtered.reduce((prev,cur)=>{return prev+cur});
}

…假设变量在超出作用域时被垃圾收集，那么它在内存使用和性能方面是否相等?

澄清一下，我理解这可以被视为微优化，我并不是在问这是否是最佳实践。

这种级别的微优化很少值得修改您的代码。尽可能用最清晰的方式编写代码。我倾向于按照这个顺序来考虑这些编码优先级:正确、清晰、健壮、可重用、注释和适当的性能基本上就是这个顺序。由于这个问题的性能增量不太可能是相关的，而且它是最后一个优先级，那么在它之前出现的其他优先级应该指导思考。

如果你只是想知道内部发生了什么，你会发现可能没有什么不同。

当您运行.filter()时，在您的任何一个代码示例中都会生成一个新的数组。

因此，两者之间的唯一区别是，在第二个代码示例中，您将其分配给临时变量，然后在该临时变量上调用.reduce()。在第二个代码示例中没有生成新的数组，只是创建了一个额外的局部变量和一个额外的变量赋值。在函数中执行其他操作的一般方案中(特别是如果数组具有合理的大小)，您将进行许多其他函数调用，因此这一个额外的变量赋值不太可能相关。

也就是说，如果中间值不需要用于其他任何东西，那么许多人会认为，由于不需要保留中间结果或对其赋值，甚至不需要拥有该变量，因此只需将结果链接起来，代码就会更简洁。

尽管如此，这并不是一个普遍的真理。捆绑并不总是更好的解决方案。有时，代码变得非常复杂，以至于将长而大的链式语句分解成一些命名的中间结果会使代码更容易理解，并且在某些情况下，更容易调试(因为更容易看到中间结果)。在您的特定代码中，一些链式操作看起来非常好，所以我个人不会使用中间变量。

相关文章：