「译」更快的 async 函数和 promises

翻译自：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)，咱们致力于异步代码的性能优化，目前的效果还不错，你能够放心地使用这些新特性。

上面的是 doxbee 基准测试，用于反应重度使用 promise 的性能，图中纵坐标表示执行时间，因此越小越好。

另外一方面，parallel 基准测试 反应的是重度使用 Promise.all() 的性能状况，结果以下：

Promise.all 的性能提升了八倍！

而后，上面的测试仅仅是小的 DEMO 级别的测试，V8 团队更关心的是 实际用户代码的优化效果。

上面是基于市场上流行的 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 里的结果是：

虽然以上结果符合预期，可是却不符合规范。Node.js 10 纠正了这个行为，会先执行 then 链里的，而后才是 async 函数。

这个「正确的行为」看起来并不正常，甚至会让不少 JavaScript 开发者感到吃惊，仍是有必要再详细解释下。在解释以前，咱们先从一些基础开始。

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

从某层面上来讲，JavaScript 里存在任务和微任务。任务处理 I/O 和计时器等事件，一次只处理一个。微任务是为了 async/await 和 promise 的延迟执行设计的，每次任务最后执行。在返回事件循环（event loop）前，微任务的队列会被清空。

能够经过 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）。

而后是有意思的东西来了：真正的 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 会被放到下个周期执行。

而后，引擎建立了另外一个叫作 throwaway 的 promise。之因此叫这个名字，由于没有其它东西链过它，仅仅是引擎内部用的。throwaway promise 会链到含有恢复处理函数的 promise 上。这里 performPromiseThen 操做其实内部就是 Promise.prototype.then()。最终，该 async 函数会暂停，并把控制权交给调用者。

调用者会继续执行，最终调用栈会清空，而后引擎会开始执行微任务：运行以前已准备就绪的 PromiseResolveThenableJob，首先是一个 PromiseReactionJob，它的工做仅仅是在传递给 await 的值上封装一层 promise。而后，引擎回到微任务队列，由于在回到事件循环以前微任务队列必需要清空。

而后是另外一个 PromiseReactionJob，等待咱们正在 await（咱们这里指的是 42）这个 promise 完成，而后把这个动做安排到 throwaway promise 里。引擎继续回到微任务队列，由于还有最后一个微任务。

如今这第二个 PromiseReactionJob 把决定传达给 throwaway promise，并恢复 async 函数的执行，最后返回从 await 获得的 42。

总结下，对于每个 await 引擎都会建立两个额外的 promise（即便右值已是一个 promise），而且须要至少三个微任务。谁会想到一个简单的 await 居然会有如此多冗余的运算？！

咱们来看看究竟是什么引发冗余。第一行的做用是封装一个 promise，第二行为了 resolve 封装后的 promose await 以后的值 v。这两行产生个冗余的 promise 和两个冗余的微任务。若是 v 已是 promise 的话就很不划算了（大多时候确实也是如此）。在某些特殊场景 await 了 42 的话，那确实仍是须要封装成 promise 的。

所以，这里可使用 promiseResolve 操做来处理，只有必要的时候才会进行 promise 的封装：

若是入参是 promise，则原封不动地返回，只封装必要的 promise。这个操做在值已是 promose 的状况下能够省去一个额外的 promise 和两个微任务。此特性能够经过 --harmony-await-optimization 参数在 V8（从 v7.1 开始）中开启，同时咱们 向 ECMAScript 发起了一个提案，目测很快会合并。

下面是简化后的 await 执行过程：

感谢神奇的 promiseResolve，如今咱们只须要传 v 便可而不用关心它是什么。以后跟以前同样，引擎会建立一个 throwaway promise 并放到 PromiseReactionJob 里为了在下一个 tick 时恢复该 async 函数，它会先暂停函数，把自身返回给掉用者。

当最后全部执行完毕，引擎会跑微任务队列，会执行 PromiseReactionJob。这个任务会传递 promise 结果给 throwaway，而且恢复 async 函数，从 await 拿到 42。

尽管是内部使用，引擎建立 throwaway promise 可能仍是会让人以为哪里不对。事实证实，throwaway promise 仅仅是为了知足规范里 performPromiseThen 的须要。

这是最近提议给 ECMAScript 的 变动，引擎大多数时候再也不须要建立 throwaway 了。

对比 await 在 Node.js 10 和优化后（应该会放到 Node.js 12 上）的表现：

async/await 性能超过了手写的 promise 代码。关键就是咱们减小了 async 函数里一些没必要要的开销，不只仅是 V8 引擎，其它 JavaScript 引擎都经过这个 补丁 实现了优化。

开发体验优化

除了性能，JavaScript 开发者也很关心问题定位和修复，这在异步代码里一直不是件容易的事。Chrome DevTools 如今支持了异步栈追踪：

在本地开发时这是个颇有用的特性，不过一旦应用部署了就没啥用了。调试时，你只能看到日志文件里的 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 。