拆分JavaScript长计算任务：Chrome浏览器下的异常性能表现

这两个问题的核心其实都和不同浏览器的JS引擎（Chrome的V8 vs Firefox的SpiderMonkey）以及事件循环调度机制的差异有关，咱们一个个来拆解：

1. 为什么Chrome中同步与异步执行的耗时差异巨大？ #

• 定时器的最小延迟开销：Chrome里setTimeout(fn, 0)并不是真正的0毫秒执行。根据HTML标准，定时器存在最小4ms的延迟限制（尤其是当嵌套调用超过一定次数后，这个限制会被严格触发）。你的代码循环了1000次，每次异步调用都要等待这个最小延迟，累计下来就产生了巨大的额外耗时，而同步执行是连续占用主线程，完全没有这些调度等待的时间。
• V8引擎的JIT优化差异：Chrome的V8引擎对连续执行的同步代码会做非常激进的优化，比如把整个循环内的逻辑编译成高度优化的机器码，甚至做循环展开、常量折叠等深度优化。但异步执行时，每次performLongComputations都是通过setTimeout触发的独立宏任务，V8的JIT无法把这些分散的调用串联起来做持续优化，每次调用都要额外处理上下文切换和优化状态的重建，自然会慢很多。
• 主线程的资源抢占：同步执行时，浏览器的其他主线程任务（比如UI渲染、垃圾回收）都被完全阻塞，JS引擎可以全力投入计算；而异步执行时，每次宏任务之间，浏览器会趁机处理后台任务（比如GC、渲染队列），这些任务会抢占一部分CPU时间，进一步拉长了总耗时。

2. 为什么Firefox中异步执行通常比同步执行更快？ #

• SpiderMonkey的优化策略：Firefox的SpiderMonkey引擎在处理分散的异步任务时，优化逻辑和V8不同。它可能对多次独立调用的同一函数能保持住优化状态，不会因为宏任务的间隔而丢失优化效果，所以异步调用的性能损耗很小。
• 定时器延迟的实现差异：Firefox对setTimeout(0)的实际延迟处理比Chrome更宽松，实际等待时间更接近0，大幅减少了调度的额外开销，让异步任务的执行间隔几乎可以忽略。
• 垃圾回收的时机优势：同步执行时，长时间的连续计算会让临时变量（比如每次循环的sum）持续堆积，直到整个同步任务结束后才会触发垃圾回收，期间内存碎片化或高占用可能影响计算效率。而异步执行时，每次宏任务间隙，浏览器可以及时执行垃圾回收，清理掉上一次计算产生的无用变量，让后续计算在更干净的内存环境下进行，避免了GC暂停对性能的影响。
• 主线程阻塞的隐性限制：Firefox可能对长时间阻塞主线程的同步任务有一些隐性的性能限制（比如降低JIT优化优先级），而异步任务因为每次执行时间较短，不会触发这些限制，所以整体表现反而略好于同步执行。

内容的提问来源于stack exchange，提问作者pawel2101