Cubelrti's Blog

Promise Optimization

image | left 翻译自：Faster async functions and promises JavaScript 的异步过程一直被认为是不够快的，更糟糕的是，在 NodeJS 等实时性要求高的场景下调试堪比噩梦。不过，这一切正在改变，这篇文章会详细解释我们是如何优化 V8 引擎（也会涉及一些其它引擎）里的 async 函数和 promises 的，以及伴随着的开发体验的优化。 温馨提示： 这里有个 视频，你可以结合着文章看。

异步编程的新方案

从 callbacks 到 promises，再到 async 函数

在 promises 正式成为 JavaScript 标准的一部分之前，回调被大量用在异步编程中，下面是个例子：

function handler(done) {
  validateParams((error) => {
    if (error) return done(error);
    dbQuery((error, dbResults) => {
      if (error) return done(error);
      serviceCall(dbResults, (error, serviceResults) => {
        console.log(result);
        done(error, serviceResults);
      });
    });
  });
}

类似以上深度嵌套的回调通常被称为「回调黑洞」，因为它让代码可读性变差且不易维护。 幸运地是，现在 promises 成为了 JavaScript 语言的一部分，以下实现了跟上面同样的功能：

function handler() {
  return validateParams()
    .then(dbQuery)
    .then(serviceCall)
    .then(result => {
      console.log(result);
      return result;
    });
}

最近，JavaScript 支持了 async 函数，上面的异步代码可以写成像下面这样的同步的代码：

async function handler() {
  await validateParams();
  const dbResults = await dbQuery();
  const results = await serviceCall(dbResults);
  console.log(results);
  return results;
}

借助 async 函数，代码变得更简洁，代码的逻辑和数据流都变得更可控，当然其实底层实现还是异步。（注意，JavaScript 还是单线程执行，async 函数并不会开新的线程。）

从事件监听回调到 async 迭代器

NodeJS 里 ReadableStreams 作为另一种形式的异步也特别常见，下面是个例子：

const http = require('http');
http.createServer((req, res) => {
  let body = '';
  req.setEncoding('utf8');
  req.on('data', (chunk) => {
    body += chunk;
  });
  req.on('end', () => {
    res.write(body);
    res.end();
  });
}).listen(1337);

这段代码有一点难理解：只能通过回调去拿 chunks 里的数据流，而且数据流的结束也必须在回调里处理。如果你没能理解到函数是立即结束但实际处理必须在回调里进行，可能就会引入 bug。 同样很幸运，ES2018 特性里引入的一个很酷的 async 迭代器 可以简化上面的代码：

const http = require('http');
http.createServer(async (req, res) => {
  try {
    let body = '';
    req.setEncoding('utf8');
    for await (const chunk of req) {
      body += chunk;
    }
    res.write(body);
    res.end();
  } catch {
    res.statusCode = 500;
    res.end();
  }
}).listen(1337);

你可以把所有数据处理逻辑都放到一个 async 函数里使用 for await…of 去迭代 chunks，而不是分别在 'data' 和 'end' 回调里处理，而且我们还加了 try-catch 块来避免 unhandledRejection 问题。 以上这些特性你今天就可以在生成环境使用！async 函数__从 Node.js 8 (V8 v6.2 / Chrome 62) 开始就已全面支持__，async 迭代器__从 Node.js 10 (V8 v6.8 / Chrome 68) 开始支持__。

async 性能优化

从 V8 v5.5 (Chrome 55 & Node.js 7) 到 V8 v6.8 (Chrome 68 & Node.js 10)，我们致力于异步代码的性能优化，目前的效果还不错，你可以放心地使用这些新特性。 image | left 上面的是 doxbee 基准测试，用于反应重度使用 promise 的性能，图中纵坐标表示执行时间，所以越小越好。 另一方面，parallel 基准测试 反应的是重度使用 Promise.all() 的性能情况，结果如下： image | left Promise.all 的性能提高了__八倍__！ 然后，上面的测试仅仅是小的 DEMO 级别的测试，V8 团队更关心的是 实际用户代码的优化效果。 image | left 上面是基于市场上流行的 HTTP 框架做的测试，这些框架大量使用了 promises 和 async 函数，这个表展示的是每秒请求数，所以跟之前的表不一样，这个是数值越大越好。从表可以看出，从 Node.js 7 (V8 v5.5) 到 Node.js 10 (V8 v6.8) 性能提升了不少。 性能提升取决于以下三个因素：

  • TurboFan，新的优化编译器 🎉
  • Orinoco，新的垃圾回收器 🚛
  • 一个 Node.js 8 的 bug 导致 await 跳过了一些微 tick（microticks） 🐛 当我们在 Node.js 8 里 启用 TurboFan 的后，性能得到了巨大的提升。 同时我们引入了一个新的垃圾回收器，叫作 Orinoco，它把垃圾回收从主线程中移走，因此对请求响应速度提升有很大帮助。 最后，Node.js 8 中引入了一个 bug 在某些时候会让 await 跳过一些微 tick，这反而让性能变好了。这个 bug 是因为无意中违反了规范导致的，但是却给了我们优化的一些思路。这里我们稍微解释下：
const p = Promise.resolve();
(async () => {
  await p; console.log('after:await');
})();
p.then(() => console.log('tick:a'))
 .then(() => console.log('tick:b'));

上面代码一开始创建了一个已经完成状态的 promise p，然后 await 出其结果，又同时链了两个 then，那最终的 console.log 打印的结果会是什么呢？ 因为 p 是已完成的，你可能认为其会先打印 'after:await'，然后是剩下两个 tick, 事实上 Node.js 8 里的结果是： image | left 虽然以上结果符合预期，但是却不符合规范。Node.js 10 纠正了这个行为，会先执行 then 链里的，然后才是 async 函数。 image | left 这个「正确的行为」看起来并不正常，甚至会让很多 JavaScript 开发者感到吃惊，还是有必要再详细解释下。在解释之前，我们先从一些基础开始。

任务（tasks）vs. 微任务（microtasks）

从某层面上来说，JavaScript 里存在任务和微任务。任务处理 I/O 和计时器等事件，一次只处理一个。微任务是为了 async/await 和 promise 的延迟执行设计的，每次任务最后执行。在返回事件循环（event loop）前，微任务的队列会被清空。 image | left 可以通过 Jake Archibald 的 tasks, microtasks, queues, and schedules in the browser 了解更多。Node.js 里任务模型与此非常类似。

async 函数

根据 MDN，async 函数是一个通过异步执行并隐式返回 promise 作为结果的函数。从开发者角度看，async 函数让异步代码看起来像同步代码。 一个最简单的 async 函数：

async function computeAnswer() {
  return 42;
}

函数执行后会返回一个 promise，你可以像使用其它 promise 一样用其返回的值。

const p = computeAnswer();
// → Promise
p.then(console.log);
// prints 42 on the next turn

你只能在下一个微任务执行后才能得到 promise p 返回的值，换句话说，上面的代码语义上等价于使用 Promise.resolve 得到的结果：

function computeAnswer() {
  return Promise.resolve(42);
}

async 函数真正强大的地方来源于 await 表达式，它可以让一个函数执行暂停直到一个 promise 已接受（resolved），然后等到已完成（fulfilled）后恢复执行。已完成的 promise 会作为 await 的值。这里的例子会解释这个行为：

async function fetchStatus(url) {
  const response = await fetch(url);
  return response.status;
}

fetchStatus 在遇到 await 时会暂停，当 fetch 这个 promise 已完成后会恢复执行，这跟直接链式处理 fetch 返回的 promise 某种程度上等价。

function fetchStatus(url) {
  return fetch(url).then(response => response.status);
}

链式处理函数里包含了之前跟在 await 后面的代码。 正常来说你应该在 await 后面放一个 Promise，不过其实后面可以跟任意 JavaScript 的值，如果跟的不是 promise，会被制转为 promise，所以 await 42 效果如下：

async function foo() {
  const v = await 42;
  return v;
}
const p = foo();
// → Promise
p.then(console.log);
// prints `42` eventually

更有趣的是，await 后可以跟任何 “thenable”，例如任何含有 then 方法的对象，就算不是 promise 都可以。因此你可以实现一个有意思的 类来记录执行时间的消耗：

class Sleep {
  constructor(timeout) {
    this.timeout = timeout;
  }
  then(resolve, reject) {
    const startTime = Date.now();
    setTimeout(() => resolve(Date.now() - startTime),
               this.timeout);
  }
}
(async () => {
  const actualTime = await new Sleep(1000);
  console.log(actualTime);
})();

一起来看看 V8 规范 里是如何处理 await 的。下面是很简单的 async 函数 foo：

async function foo(v) {
  const w = await v;
  return w;
}

执行时，它把参数 v 封装成一个 promise，然后会暂停直到 promise 完成，然后 w 赋值为已完成的 promise，最后 async 返回了这个值。

神秘的 await

首先，V8 会把这个函数标记为可恢复的，意味着执行可以被暂停并恢复（从 await 角度看是这样的）。然后，会创建一个所谓的 implicit_promise（用于把 async 函数里产生的值转为 promise）。 image | left 然后是有意思的东西来了：真正的 await。首先，跟在 await 后面的值被转为 promise。然后，处理函数会绑定这个 promise 用于在 promise 完成后恢复主函数，此时 async 函数被暂停了，返回 implicit_promise 给调用者。一旦 promise 完成了，函数会恢复并拿到从 promise 得到值 w，最后，implicit_promise 会用 w 标记为已接受。 简单说，await v 初始化步骤有以下组成：

  1. 把 v 转成一个 promise（跟在 await 后面的）。
  2. 绑定处理函数用于后期恢复。
  3. 暂停 async 函数并返回 implicit_promise 给掉用者。 我们一步步来看，假设 await 后是一个 promise，且最终已完成状态的值是 42。然后，引擎会创建一个新的 promise 并且把 await 后的值作为 resolve 的值。借助标准里的 PromiseResolveThenableJob 这些 promise 会被放到下个周期执行。 image | left 然后，引擎创建了另一个叫做 throwaway 的 promise。之所以叫这个名字，因为没有其它东西链过它，仅仅是引擎内部用的。throwaway promise 会链到含有恢复处理函数的 promise 上。这里 performPromiseThen 操作其实内部就是 Promise.prototype.then()。最终，该 async 函数会暂停，并把控制权交给调用者。 image | left 调用者会继续执行，最终调用栈会清空，然后引擎会开始执行微任务：运行之前已准备就绪的 PromiseResolveThenableJob，首先是一个 PromiseReactionJob，它的工作仅仅是在传递给 await 的值上封装一层 promise。然后，引擎回到微任务队列，因为在回到事件循环之前微任务队列必须要清空。 image | left 然后是另一个 PromiseReactionJob，等待我们正在 await（我们这里指的是 42）这个 promise 完成，然后把这个动作安排到 throwaway promise 里。引擎继续回到微任务队列，因为还有最后一个微任务。 image | left 现在这第二个 PromiseReactionJob 把决定传达给 throwaway promise，并恢复 async 函数的执行，最后返回从 await 得到的 42。 image | left 总结下，对于每一个 await 引擎都会创建__两个额外__的 promise（即使右值已经是一个 promise），并且需要__至少三个__微任务。谁会想到一个简单的 await 竟然会有如此多冗余的运算？！ image | left 我们来看看到底是什么引起冗余。第一行的作用是封装一个 promise，第二行为了 resolve 封装后的 promose await 之后的值 v。这两行产生个冗余的 promise 和两个冗余的微任务。如果 v 已经是 promise 的话就很不划算了（大多时候确实也是如此）。在某些特殊场景 await 了 42 的话，那确实还是需要封装成 promise 的。 因此，这里可以使用 promiseResolve 操作来处理，只有必要的时候才会进行 promise 的封装： image | left 如果入参是 promise，则原封不动地返回，只封装必要的 promise。这个操作在值已经是 promose 的情况下可以省去一个额外的 promise 和两个微任务。此特性可以通过 --harmony-await-optimization 参数在 V8（从 v7.1 开始）中开启，同时我们 向 ECMAScript 发起了一个提案，目测很快会合并。 下面是简化后的 await 执行过程： image | left 感谢神奇的 promiseResolve，现在我们只需要传 v 即可而不用关心它是什么。之后跟之前一样，引擎会创建一个 throwaway promise 并放到 PromiseReactionJob 里为了在下一个 tick 时恢复该 async 函数，它会先暂停函数，把自身返回给掉用者。 image | left 当最后所有执行完毕，引擎会跑微任务队列，会执行 PromiseReactionJob。这个任务会传递 promise 结果给 throwaway，并且恢复 async 函数，从 await 拿到 42。 image | left 尽管是内部使用，引擎创建 throwaway promise 可能还是会让人觉得哪里不对。事实证明，throwaway promise 仅仅是为了满足规范里 performPromiseThen 的需要。 image | left 这是最近提议给 ECMAScript 的 变更，引擎大多数时候不再需要创建 throwaway 了。 image | left 对比 await 在 Node.js 10 和优化后（应该会放到 Node.js 12 上）的表现： image | left async/await 性能超过了手写的 promise 代码。关键就是我们减少了 async 函数里一些不必要的开销，不仅仅是 V8 引擎，其它 JavaScript 引擎都通过这个 补丁 实现了优化。

开发体验优化

除了性能，JavaScript 开发者也很关心问题定位和修复，这在异步代码里一直不是件容易的事。Chrome DevTools 现在支持了异步栈追踪： image | left 在本地开发时这是个很有用的特性，不过一旦应用部署了就没啥用了。调试时，你只能看到日志文件里的 Error#stack 信息，这些并不会包含任何异步信息。 最近我们搞的 零成本异步栈追踪 使得 Error#stack 包含了 async 函数的调用信息。「零成本」听起来很让人兴奋，对吧？当 Chrome DevTools 功能带来重大开销时，它如何才能实现零成本？举个例子，foo 里调用 bar，bar 在 await 一个 promise 后抛一个异常：

async function foo() {
  await bar();
  return 42;
}
async function bar() {
  await Promise.resolve();
  throw new Error('BEEP BEEP');
}
foo().catch(error => console.log(error.stack));

这段代码在 Node.js 8 或 Node.js 10 运行结果如下：

$ node index.js
Error: BEEP BEEP
    at bar (index.js:8:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:266:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)

注意到，尽管是 foo() 里的调用抛的错，foo 本身却不在栈追踪信息里。如果应用是部署在云容器里，这会让开发者很难去定位问题。 有意思的是，引擎是知道 bar 结束后应该继续执行什么的：即 foo 函数里 await 后。恰好，这里也正是 foo 暂停的地方。引擎可以利用这些信息重建异步的栈追踪信息。有了以上优化，输出就会变成这样：

$ node --async-stack-traces index.js
Error: BEEP BEEP
    at bar (index.js:8:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:266:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)
    at async foo (index.js:2:3)

在栈追踪信息里，最上层的函数出现在第一个，之后是一些异步调用栈，再后面是 foo 里面 bar 上下文的栈信息。这个特性的启用可以通过 V8 的 --async-stack-traces 参数启用。 然而，如果你跟上面 Chrome DevTools 里的栈信息对比，你会发现栈追踪里异步部分缺失了 foo 的调用点信息。这里利用了 await 恢复和暂停位置是一样的特性，但 Promise#then() 或 Promise#catch() 就不是这样的。可以看 Mathias Bynens 的文章 await beats Promise#then() 了解更多。

结论

async 函数变快少不了以下两个优化：

  • 移除了额外的两个微任务
  • 移除了 throwaway promise 除此之外，我们通过 零成本异步栈追踪 提升了 await 和 Promise.all() 开发调试体验。 我们还有些对 JavaScript 开发者友好的性能建议： 多使用 async 和 await 而不是手写 promise 代码，多使用 JavaScript 引擎提供的 promise 而不是自己去实现。

文章可随意转载，但请保留此 原文链接。 非常欢迎有激情的你加入 ES2049 Studio，简历请发送至 caijun.hcj(at)alibaba-inc.com 。

← Prototype Review →