数组操作方法性能对比 - map/filter/reduce/for 循环

核心原因：函数调用开销。map/filter/reduce 每次迭代都需要调用一个回调函数，而函数调用涉及栈帧创建、上下文切换、参数传递等额外开销。for 循环直接内联执行操作，避免了这些开销。此外，map/filter 还需要动态构建新数组（内存分配和扩容），而优化得当的 for 循环可以预分配数组大小。在 V8 引擎中，for 循环还更容易触发内联缓存（Inline Caching）优化。不过，随着 JIT 编译器技术的进步，差距正在缩小。

以下场景建议优先使用声明式方法：
① 需要链式操作时：arr.filter(...).map(...).reduce(...) 一气呵成，可读性极佳；
② 数据处理管道：在数据转换流程中，map/filter/reduce 清晰表达了每一步的意图；
③ 团队代码规范：许多团队推崇函数式风格，统一使用声明式方法减少认知负担；
④ 数据量较小（<10,000）：性能差异微乎其微（通常 <1ms），优先保证代码质量；
⑤ 不可变数据：map/filter 返回新数组，符合不可变性原则，减少副作用风险。

预热（Warmup）指在正式计时前，先执行几次相同的操作但不记录时间。其重要性在于：
① JIT 编译触发：V8 等引擎的 TurboFan 编译器需要观察到函数被多次调用后才会进行深度优化。预热确保测试的是优化后的代码；
② CPU 缓存预热：数据和指令被加载到 L1/L2 缓存后，后续访问更快；
③ 消除首次开销：首次执行可能包含类加载、惰性初始化等一次性成本。本工具默认预热 2 次，确保结果反映稳态性能。

数组大小对性能对比的影响是非线性的：
• 小数组（<1000）：函数调用开销占比高，for 循环优势明显（可能快 2-5 倍），但绝对时间差异极小（微秒级），实际意义不大；
• 中等数组（1K-100K）：这是最常见的实际场景，各方法性能差距缩小到 1.5-3 倍，内存分配和 GC 开始显现影响；
• 大数组（>100K）：内存带宽成为瓶颈，方法间差距进一步缩小。某些引擎对 map/filter 有特殊优化（如内联数组分配），可能反超简单 for 循环；
• 超大型（>1M）：垃圾回收（GC）压力显著，使用预分配数组的 for 循环通常最优，因为减少了 GC 触发频率。

会，且差异可能很大。主流引擎包括：
• V8（Chrome/Edge/Node.js）：优化激进，for 循环和 forEach 性能接近，map 在特定模式下有快速路径；
• SpiderMonkey（Firefox）：对 reduce 有独特优化，某些场景下 reduce 可能比 for 还快；
• JavaScriptCore（Safari）：优化相对保守，for 循环通常保持明显优势；
建议在目标用户的主要浏览器上测试，或使用本工具在不同浏览器中分别运行对比。Node.js 服务端主要关注 V8 表现。

在累加求和场景中，reduce 通常比优化过的 for 循环慢 20%-80%（取决于数组大小和引擎）。但 reduce 的价值在于：
① 语义清晰：一眼可知"将数组归约为单个值"；
② 不易出错：for 循环的索引边界、累加器初始化等容易写错，reduce 消除了这些隐患；
③ 与函数式生态兼容：易于与 map/filter 组合成管道；
④ 可测试性强：reduce 的回调可以单独提取和单元测试。对于绝大多数业务场景，reduce 带来的可维护性收益远超微小的性能代价。

在现代 JS 引擎中，箭头函数和普通匿名函数在数组方法回调中的性能几乎相同（差异 <2%）。早期引擎中箭头函数因没有自己的 this 绑定和 arguments 对象而略快，但现在的优化已抹平差距。真正影响性能的是：① 函数体内联程度（简单表达式比复杂逻辑更容易被内联）；② 闭包引用（引用外部变量会阻止某些优化）。建议优先考虑代码可读性。