异步/等待本机实现 [英] async/await native implementations

问题描述

这个提议建议async函数可以使用引擎盖下的生成器函数，尽管我在 ES2017 规范中找不到对此的确认.

This proposal suggests that async functions can use generator functions under the hood, although I cannot find a confirmation of this in ES2017 spec.

此外，当生成器原型在 Chrome/Node.js 中变得混乱时，async 函数似乎没有受到影响，这表明没有使用 GeneratorFunction通过 AsyncFunction，至少直接:

Moreover, when generator prototype becomes messed up in Chrome/Node.js, async functions don't seem to be affected, this suggests that GeneratorFunction isn't used by AsyncFunction, at least directly:

Object.getPrototypeOf((function * () {}).prototype).next = null;

(async () => {
    return await Promise.resolve(1);
})()
.then(console.log);

async/await 在现有的原生实现中究竟是如何工作的?

How exactly does async/await work in existing native implementations?

这些实现是否比提案中建议的 Promise/generator 函数方法的性能更高，通常在 Babel 和 TypeScript 中实现?

Are the implementations more performant than it would be possible with Promise/generator function approach that is suggested by the proposal and is usually implemented in Babel and TypeScript?

推荐答案

async/await 在现有的原生实现中究竟是如何工作的?

How exactly does async/await work in existing native implementations?

如果我们看看实际的 v8 中异步等待的本机实现 我们可以清楚地看到承诺和生成器都是异步等待实现的明显基础，同样在 parser 它清楚地说明了 desugaring async-await 的生成器承诺性质.

If we look at the actual native implementation of async await in v8 we can clearly see both promise and generator as the obvious basis of async-await implementation, also in the parser it clearly states the generator-promise nature of desugaring async-await.

关于 ES 规范，尽管规范没有直接提到执行上下文切换的实际实现，但它暗示了使用相同的 执行！调用(promiseCapability.[[Resolve]]机制Promise.resolve 正在使用.因此主观暗示了可能的机制"来处理 asyncContext 的运行执行上下文切换.

Regarding ES spec, even though the spec doesn't directly mention the actual implementation of execution context switching, it hints usage of same Perform ! Call(promiseCapability.[[Resolve]] mechanism the Promise.resolve is using. Thus subjectively hinting the possible "mechanism" to handle running execution context toggling of asyncContext.

此外，当生成器原型在 Chrome/Node.js 中变得一团糟时，异步函数似乎没有受到影响，这表明 AsyncFunction 没有使用 GeneratorFunction，至少没有直接使用:

Moreover, when generator prototype becomes messed up in Chrome/Node.js, async functions don't seem to be affected, this suggests that GeneratorFunction isn't used by AsyncFunction, at least directly:

运行时中的 generator 和 async 函数都是 Function 对象的后代，但它们并不相互继承，那就是为什么您看不到已提交的更改.

Both generator and async functions in the runtime are descendants of the Function object, they don't inherit from one another though, that's why you don't see the committed changes.

但是特定宿主对象或方法的实际本机级实现不一定必须连接到已编译对应项及其依赖项的运行时执行，就像您无法通过重新分配Function.prototype.call = () =>{}，因为 %call% 是原生级别的实现.

But the actual native level implementation of specific host object or method doesn't have to necessarily be connected to runtime execution of compiled counterparts and their dependencies, the same way as you cannot alter the function's ability to be called by reassigning Function.prototype.call = () => {}, since %call% is a native level implementation.

这些实现是否比提案中建议的 Promise/生成器函数方法的性能更高，并且通常在 Babel 和 TypeScript 中实现?

Are the implementations more performant than it would be possible with Promise/generator function approach that is suggested by the proposal and is usually implemented in Babel and TypeScript?

它依赖于 js 引擎及其实现的编译级优化和反优化，但它会不断变化，有时本机实现比 3rd 方 lib 实现慢，例如 它发生在 es5 map, forEach vs lodash 对应物，但在大多数情况下，由于是更接近机器代码的一级.作为一个例子，这里是 2x 在 jsbench 中使用 async-await vs babel regenerator vs promise 的 async-await 流行率.

It depends on js engine and its implemented compilation level optimizations and deoptimizations, but it's subject to continuous change, sometimes native implementation is slower than the 3rd party lib implementation, like it happened with es5 map, forEach vs lodash counterparts, but in most cases native level implementation is unmatched due to being one level closer to machine code. As an example here is the 2x prevalence of async-await in jsbench with async-await vs babel regenerator vs promise.

这篇关于异步/等待本机实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！