async /等待本机实现

Question

该提议建议async功能可以使用发动机功能,虽然我在ES2017规范中找不到这方面的确认.

此外,当发电机在原型铬/ Node.js的变得一团糟,async似乎功能不受到影响,这表明GeneratorFunction不使用AsyncFunction,至少直接:

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

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

为什么说async/ await现有的本地实现的工作？

这些实现是否比Promise使用提案建议的/ generator函数方法更高效,并且通常在Babel和TypeScript中实现？

Answer 1

async/await在现有的本机实现中究竟是如何工作的？

如果我们在v8中查看async await的实际本机实现,我们可以清楚地看到promise和generator都是async-await实现的明显基础,同样在解析器中它清楚地说明了desugaring async-await的生成器承诺性质.

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

此外,当生成器原型在Chrome/Node.js中混乱时,异步函数似乎不会受到影响,这表明AsyncFunction不使用GeneratorFunction,至少直接:

运行时中的两个generator和async函数都是Function对象的后代,但它们不会相互继承,这就是您没有看到提交的更改的原因.

但是,特定主机对象或方法的实际本机级实现不一定必须连接到已编译对应项及其依赖项的运行时执行,就像您不能通过重新分配来改变函数调用的能力一样Function.prototype.call = () => {},因为%call%它是本机的水平实施.

这些实现是否比提案建议的Promise/generator函数方法更具性能,并且通常在Babel和TypeScript中实现？

它取决于js引擎及其实现的编译级别优化和去优化,但它受到持续变化的影响,有时本机实现比第三方lib实现慢,就像es5 map, forEachvs lodash对应物一样,但在大多数情况下,本机级实现是由于距离机器代码更近一层而无法比拟.这里的例子是jsperf,其中2x流行率为async-await,而不是 babel中使用的再生器.