Mathias Bynens

Asynchronous stack traces: why await beats .then()

· tagged with JavaScript, performance

Compared to using promises directly, not only can async and await make code more readable for developers — they enable some interesting optimizations in JavaScript engines, too! This write-up is about one such optimization involving stack traces for asynchronous code.

The fundamental difference between await and vanilla promises is that await X() suspends execution of the current function, while promise.then(X) continues execution of the current function after adding the X call to the callback chain. In the context of stack traces, this difference is pretty significant.

When a promise chain (desugared or not) throws an unhandled exception at any point, the JavaScript engine displays an error message and (hopefully) a useful stack trace. As a developer, you expect this regardless of whether you use vanilla promises or async and await.

Vanilla promises

Imagine a scenario where a function c is called when a call to an asynchronous function b resolves:

const a = () => {
b().then(() => c());
};

When a is called, the following happens synchronously:

  • b is called and returns a promise that will resolve at some point in the future.
  • The .then callback (which is effectively calling c()) is added to the callback chain (or, in V8 lingo: […] is added as a resolve handler).

After that, we’re done executing the code in the body of function a. a is never suspended, and the context is gone by the time the asynchronous call to b resolves. Imagine what happens if b (or c) asynchronously throws an exception. The stack trace should include a, since that’s where b (or c) was called from, right? How is that possible now that we have no reference to a anymore?

To make it work, the JavaScript engine needs to do something in addition to the above steps: it captures and stores the stack trace within a while it still has the chance. In V8, the stack trace is attached to the promise that b returns. When the promise fulfills, the stack trace is passed on so that c can use it as needed.

Capturing the stack trace takes time (i.e. degrades performance); storing these stack traces requires memory. 🐌👎

async/await

Here’s the same program, written using async/await instead of vanilla promises:

const a = async () => {
await b();
c();
};

With await, there’s no need to store the current stack trace — it’s sufficient to store a pointer from b to a. During execution of b, a is suspended, so its context is still available. If b throws an exception, the stack trace can be reconstructed on-demand by traversing these pointers. If c throws an exception, the stack trace can be constructed just like it would be for a synchronous function, because we’re still within a when that happens. Either way, stack trace capturing is no longer necessary — instead, the stack trace is only constructed when needed. Storing the pointers requires less memory than storing entire stack traces. 🚀👍

Recommendations

Like most ECMAScript features that are seemingly “just syntax sugar”, async/await is more than that.

Enable JavaScript engines to handle stack traces in a more performant and memory-efficient manner by following these recommendations:

  • Prefer async/await over desugared promises.
  • Use babel-preset-env to avoid transpiling async/await unnecessarily.

Although V8 doesn’t implement this optimization yet, following this advice ensures optimal performance once we (or other JavaScript engines) do.

In general, don’t transpile code unless you absolutely need to! For example, all modern browsers that support service workers also support async/await. Consequently, there is no need to transpile your service worker–specific code down to vanilla promises. The same argument applies to browsers with ES modules support. For more information, see Philip’s blog post on deploying ES2015+ code in production today.

About me

Hi there! I’m Mathias. I work on V8 at Google. HTML, CSS, JavaScript, Unicode, performance, and security get me excited. If you managed to read this far without falling asleep, you should follow me on Twitter and GitHub.

Comments

Jett Carlo Calleja wrote on :

Is there any scenario in which we should use promises over async-await?

wrote on :

Jett: Not in your source code, no. Your transpiler may output promises if you target environments that lack async-await support, but that’s a different story.

Leave a comment

Comment on “Asynchronous stack traces: why await beats .then()

Your input will be parsed as Markdown.