为什么该JS性能测试中while(i--)循环比for循环运行速度慢？

测试用代码实现 #

const arr = Array(1000000).fill(0).map(() => Math.random());

// 1: （滥用）.forEach
let x1 = 0;
arr.forEach((i) => x1 += i);

// 2. 使用reduce
let x2 = arr.reduce((a, n) => a + n, 0);

// 3: 传统正向for-loop
let x3 = 0;
for(let i = 0; i < arr.length; i++)
    x3 += arr[i];

// 4: 反向for-loop，理论上速度更快，因为与字面量的比较运算执行速度更快
let x4 = 0;
for(let i = arr.length - 1; i >= 0; i--)
    x4 += arr[i];

// 5: 反向while-loop，理论上应最快，因为它合并了比较和自减运算
let x5 = 0;
let i = arr.length;

while(i--)
    x5 += arr[i];

性能差异原因说明 #

你观测到的性能趋势不是测试误差，是Chrome 90对应版本V8引擎的正常优化结果，核心原因如下：

• 早年「反向循环更快」「while比for快」的结论，是2010年前后JS引擎优化能力不足、CPU指令集性能较弱时代的经验，放到现在已经完全不适用。
• 传统正向for循环现在反而有优化优势：V8对这种标准的三段式for循环有专门的深度优化通路，只要数组是固定长度的稠密数组，会在编译期直接把arr.length优化为常量，不需要每次迭代读取属性，原来反向循环节省length读取的优势直接消失。同时现代CPU的整数比较指令性能完全一致，和0比较并不会比和常量比较更快，反向循环的第二个传统优势也不存在。
• 反向while循环性能更差的原因：while(i--)的写法隐含了「判断i原值是否为真 + i自减」两个绑定操作，语义不如for循环的三段式结构清晰，V8很难对这种写法触发向量化优化（即用SIMD指令一次处理多个数组元素的批量计算优化），部分场景下反而会多一层语义解析开销，所以几乎不会成为最快的实现。
• forEach和reduce性能落后符合预期：这两个数组方法每次迭代都要执行回调函数，就算引擎做了内联优化，也需要额外处理回调上下文、数组边界检查、空位判断等逻辑，额外开销远大于原生循环结构。

这类微优化的差异只有在千万级以上的循环运算中才能被观测到，业务编码完全不需要考虑，优先保证可读性即可。

内容的提问来源于stack exchange，提问作者Lukas-T