setTimeout、Promise 性能比较

setTimeout 属于宏任务（MacroTask）， Promise 属于微任务（MicroTask），二者并不在一个异步队列中。

无论是宏任务还是微任务，都是异步任务。在 JavaScript 中的异步是靠事件循环来实现的，拿大家最常见的 setTimeout 为例。 

// 同步代码
let count = 1;

setTimeout(() => {
    // 异步
  count = 2;
}, 0);

// 同步
count = 3;

 一个异步任务会被丢到事件循环的队列中，而这部分代码会在接下来同步执行的代码后面才执行（这个时序总是可靠的）。每次事件循环中，浏览器会执行队列中的任务，然后进入下一个事件循环。

当浏览器需要做一些渲染工作时，会等待这一帧的渲染工作完成，再进入下一个事件循环

如果 Promise.resolve 每次都和 setTimeout 一样往异步队列里丢一个任务然后等待一个事件循环来执行。看起来似乎没有什么大的问题，因为『事件循环』和一个 for 循环听起来似乎并没有什么本质上的不同。然后在事实上，一次事件循环的耗时是远远超出一次 for 循环的。
我们都知道 setTimeout(fn, 0) 并非真的是立即执行，而是要等待至少 4ms （事实上可能是 10ms）才会执行。

这意味着如果没有微任务的概念，我们仍然采用宏任务的机制去执行 async function（实际上就是 Promise) ，性能会非常的糟糕。

而且对于正在执行一些复杂任务的页面（例如绘制）就更加糟糕了，整个循环都会被这个任务直接阻塞。

微任务就是为了适应这种场景，和宏任务最大的不同在于，如果在执行微任务的过程中我们往任务队列中新增了任务，浏览器会全部消费掉为止，再进入下一个循环。这也是为什么微任务和宏任务的时序上会存在差别。

你会发现 setTimeout 版本的页面仍然能够操作，而控制台上 test 的输出次数在不断增加。

而 Promise.resolve 和直接递归的表现是一样的（其实有一些区别， Promise.resolve 仍然是异步执行的），标签页被卡住，Chrome Devtools 上的输出次数隔一段时间蹦一下。

了解宏任务和微任务的差异有助于我们理解 Promise 的性能。

我们在实际生产中常常发现某些环境下的 Promise 的性能表现非常不如意，有些是不同容器的实现，另一些则是不同版本的 polyfill 实现。尤其是一些开发者会更倾向于体积更小的 polyfill ，例如这个有 1.3k Star 的实现  github.com/taylorhakes…

默认就是使用 setTimout 模拟的 Promise.resolve ，我们在 jsperf.com/promise-per… 可以看到性能的对比已经有了数量级的差距（事实上比较复杂的异步任务会感觉到明显的延迟）。

除了 Promise 是微任务外，还有很多 API 也是通过微任务设定的异步任务，其实如果有了解过 Vue 源码的同学就会注意到 Vue 的 $nextTick 源码中，在没有 Promise.resolve 时就是用 MutationObserver 模拟的。

看一个简化的的 Vue.$nextTick ：

const timerFunc = (cb) => {
    let counter = 1
    const observer = new MutationObserver(cb);
    const textNode = document.createTextNode(String(counter))
    observer.observe(textNode, {
      characterData: true
    })
    counter = (counter + 1) % 2
    textNode.data = String(counter)
}

原理其实非常简单，手动构造一个 MutationObserver 然后触发 DOM 元素的改变，从而触发异步任务。

使用这种方式就明显把数量级拉了回来

由于这个 Promise 本身实现偏向于体积的缘故，这里的 benchmark 性能仍有数倍差距，但其实 bluebird 等注重性能的实现方式在 timer 函数用 MutationObserver 构造的情况下性能和原生不相上下，某些版本的浏览器下甚至更快

当然实际上 Vue 中的 NextTick 实现要更细致一些，例如通过复用 MutationObserver 的方式避免多次创建等。不过能够让 Promise 实现在性能上拉开百倍差距的就只有宏任务和微任务之间的差异。

除 MutationObserver 外还有很多其他的 API 使用的也是微任务，但从兼容性和性能角度 MutationObserver 仍然是使用最广泛的。

总结

宏任务和微任务在机制上的差异会导致不同的 Promise 实现产生巨大的性能差异，大到足以直接影响用户的直接体感。所以我们还是要避免暴力引入 Promise polyfill 的方式，在现代浏览器上优先使用 Native Promise ，而在需要 polyfill 的地方则需要避免性能出现破坏性下滑的情况。

另外，哪条 console.log 先执行看懂了就好了，真的不是问题的关键，因为你永远不应该依赖宏任务和微任务的时序差异来编程。