Discuss
  • Allow for async/await to use global.Promise and not builtin Promise

Allow for async/await to use global.Promise and not builtin Promise

# Jake Verbaten (5 years ago)

I've ported a few old fashioned callback code bases to async/await + Promises in the last year or so.

When doing performance analysis and profiling I've noticed a significant negative impact of Promise / async / await in that it adds micro tasks to the queue.

Previously there was a different link between the libuv syscall that my program made in node.js and the actual code being run in my application since callbacks are called synchronously and there is no micro task queue.

With the async / await version of the codebase profiling is proving very challenging because the stack traces all start in the micro task queue.

Would it be possible with some kind of flag or opt in mechanism to have async / await use global.Promise instead of the builtin native promise ?

This would allow me to overwrite global.Promise with a non-compliant version that has no micro task queue and invokes all the callbacks synchronously. This would greatly aid with profiling and stack traces.

Thank you, Jake.

# Jack Works (5 years ago)

this idea is useful in some ways. When I'm migrating an AngularJS app from $q (a Promise impl) to native async syntax, I got this problem too. But I think this is not the right place to add a "flag" in ES. You may want to suggest V8 or other JS engine to add a flag for it.

# medikoo (5 years ago)

+1

This would allow injecting more efficient promise alternatives without transpilation of async/await

-- Sent from: mozilla.6506.n7.nabble.com/Mozilla-ECMAScript-4-discussion-f89340.html

# Jordan Harband (5 years ago)

Anything "more efficient" would likely not be spec compliant, which would break code relying on those guarantees. Overriding any builtin is a bad practice for well over a decade, and I'm not sure why doing so would be desirable. "Fast" doesn't matter if correctness is not assured.

# medikoo (5 years ago)

Jordan Harband wrote

Anything "more efficient" would likely not be spec compliant

Promises (also those specified in ES) are quite opinionated, and I believe we should have right to practice our own opinions in our own apps.

On these grounds thenable objects (so not necessarily promise instances) are supported, and work seamlessly in promise chains.

Unfortunately async/await breaks that support, it'll be great if we can recover from that.

-- Sent from: mozilla.6506.n7.nabble.com/Mozilla-ECMAScript-4-discussion-f89340.html

# Jordan Harband (5 years ago)

You already do have that right; you can use any Promise implementation you choose, or none at all. You do not, however, typically have the "right" to alter what syntax does, and async/await explicitly chose that philosophy.

# Michał Wadas (4 years ago)

As workaround, you can use Babel to transpile only async-await. That code can be made to use any implementation of Promise that you want.

# David Teller (4 years ago)

Well, you can do that pretty easily with generators/yield instead of async/await. So, not sure it's worth it.