async /等待本机实现 [英] 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 不会被<使用code> 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 / <$ c究竟如何？ $ c>等待在现有的本机实现中工作？

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

与提案建议的 Promise / generator function方法相比，这些实现的性能是否更高并且通常用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中异步等待的本机实现我们可以清楚地看到promise和generator都是明显的async-await实现的基础，也在解析器它清楚地说明了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.

Regar ding 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:

运行时中的生成器和 async 函数都是函数对象，它们不会相互继承，这就是为什么你没有看到提交的更改。

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 / 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?

它取决于js引擎及其实现的编译级别优化和去优化，但它会不断变化，有时本机实现比第三方lib实现慢，如它发生在es5 地图上，forEach vs lodash同行 ，但在大多数情况下，本机级实现是无与伦比的，因为它更接近机器代码。这里的例子是 jsperf，在再生器上有2倍流量的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 jsperf with 2x prevalence of async-await over regenerator used in babel.

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