时间戳

首页 > 解决方案 > 为什么添加立即调用的 lambda 会使我的 JavaScript 代码快 2 倍？

javascript - 为什么添加立即调用的 lambda 会使我的 JavaScript 代码快 2 倍？

问题描述

我正在将一种语言的编译器优化为 JavaScript，并发现了一个非常有趣（如果不是令人沮丧的话）的案例：

function add(n,m) {
  return n === 0 ? m : add(n - 1, m) + 1;
};
var s = 0;
for (var i = 0; i < 100000; ++i) {
  s += add(4000, 4000);
}
console.log(s);

它需要2.3s在我的机器上完成[1]。但是如果我做一个很小的改变：

function add(n,m) {
  return (() => n === 0 ? m : add(n - 1, m) + 1)();
};
var s = 0;
for (var i = 0; i < 100000; ++i) {
  s += add(4000, 4000);
}
console.log(s);

它在1.1s. (() => ...)()请注意，唯一的区别是在返回的周围添加了立即调用的 lambda, add。为什么这个添加的调用使我的程序快了两倍？

[1] MacBook Pro 13" 2020，2.3 GHz 四核 Intel Core i7，Node.js v15.3.0

标签： javascriptnode.jsoptimizationv8compiler-optimization

解决方案

有趣的！从代码来看，很明显 IIFE 包装的版本应该更慢，而不是更快：在每次循环迭代中，它都会创建一个新的函数对象并调用它（优化编译器最终会避免这种情况，但这并没有） t 马上开始），所以通常只是做更多的工作，这应该需要更多的时间。

这种情况下的解释是内联。

一点背景知识：将一个函数内联到另一个函数（而不是调用它）是优化编译器为了获得更好的性能而执行的标准技巧之一。虽然这是一把双刃剑：从好的方面来说，它避免了调用开销，并且通常可以实现进一步的优化，例如不断传播或消除重复计算（参见下面的示例）。不利的一面是，它会导致编译花费更长的时间（因为编译器会做更多的工作），并且会导致生成更多代码并将其存储在内存中（因为内联函数有效地复制了它），并且在像 JavaScript 这样的动态语言中优化的代码通常依赖于受保护的假设，

一般来说，做出完美的内联决策（不要太多，也不要太少）需要预测未来：提前知道代码执行的频率和参数。这当然是不可能的，因此优化编译器使用各种规则/“启发式”来猜测什么可能是一个相当好的决定。

V8 目前的一条规则是：不要内联递归调用。

这就是为什么在您的代码的更简单版本中，add不会内联到自身中。IIFE 版本本质上有两个函数相互调用，称为“相互递归”——事实证明，这个简单的技巧足以欺骗 V8 的优化编译器并使其回避其“不要内联递归调用”规则. 相反，它会愉快地将未命名的 lambda 内联到add，然后add内联到未命名的 lambda 中，依此类推，直到它的内联预算在大约 30 轮后用完。（旁注：“有多少内联”是一种有点复杂的启发式方法，特别是考虑到函数大小，所以我们在这里看到的任何具体行为确实是针对这种情况的。）

在这个特殊场景中，涉及的函数非常小，内联很有帮助，因为它避免了调用开销。所以在这种情况下，内联提供了更好的性能，即使它是递归内联的（伪装）情况，通常通常对性能不利。而且它确实是有代价的：在简单版本中，优化编译器只花费 3 毫秒的时间来编译add，为它生成 562 字节的优化代码。在 IIFE 版本中，编译器花费 30 毫秒并生成 4318 字节的优化代码add. 这就是为什么它不像得出“V8 应该总是内联更多”那么简单的一个原因：编译的时间和电池消耗很重要，内存消耗也很重要，以及在一个简单的 10 行中什么可能是可接受的成本（并显着提高性能）在一个 100,000 行的应用程序中，演示很可能具有不可接受的成本（甚至可能会降低整体性能）。

现在，在了解了发生了什么之后，我们可以回到“IIFE 有开销”的直觉，并制作一个更快的版本：

function add(n,m) {
  return add_inner(n, m);
};
function add_inner(n, m) {
  return n === 0 ? m : add(n - 1, m) + 1;
}

在我的机器上，我看到：

  • 简单版：1650 毫秒
  • IIFE 版本：720 毫秒
  • add_inner 版本：460 毫秒

当然，如果你add(n, m)简单地实现 as return n + m，那么它会在 2 毫秒内终止——算法优化胜过优化编译器可能完成的任何事情 :-)

附录：优化的好处示例。考虑这两个函数：

function Process(x) {
  return (x ** 2) + InternalDetail(x, 0, 2);
}

function InternalDetail(x, offset, power) {
  return (x + offset) ** power;
}

（显然，这是愚蠢的代码；但让我们假设它是在实践中有意义的简化版本。）
当天真地执行时，会发生以下步骤：

  1. 评估temp1 = (x ** 2)
  2. InternalDetail带参数调用x, 0,2
  3. 评估temp2 = (x + 0)
  4. 评估temp3 = temp2 ** 2
  5. 返回temp3给调用者
  6. 评估temp4 = temp1 + temp3
  7. 返回temp4。

如果优化编译器执行内联，那么第一步它将获得：

function Process_after_inlining(x) {
  return (x ** 2) + ( (x + 0) ** 2 );
}

它允许两个简化：x + 0可以折叠为 just x，然后x ** 2计算发生两次，因此第二次出现可以通过重用第一次的结果来替换：

function Process_with_optimizations(x) {
  let temp1 = x ** 2;
  return temp1 + temp1;
}

因此，与天真的执行相比，我们从 7 个步骤减少到 3 个步骤：

  1. 评估temp1 = (x ** 2)
  2. 评估temp2 = temp1 + temp1
  3. 返回temp2

我并不预测现实世界的性能会从 7 个时间单位变为 3 个时间单位；这只是为了直观地了解为什么内联可以帮助减少一定数量的计算负载。
脚注：为了说明所有这些东西是多么棘手，请考虑在 JavaScriptx + 0中用 just替换x并不总是可能的，即使编译器知道它x总是一个数字：如果x碰巧是-0，那么添加0它会将其更改为+0，这很可能是可观察的程序行为；-)

推荐阅读