Performance guidelines for Async/Await in Node Version 8

Question

async/await is available with node version 8. The code is linear for the first time in nodejs, natively. That is nice. Earlier many articles claimed that, in v

Answer 1

I found a Performance of native ES2015 promises and ES2017 async functions in Node.js v8

Performance of Callbacks vs Promises vs Async Functions in Node.js v8

Both native Chrome V8 ES2015 promises and ES2017 async functions perform roughly 2 times slower than Bluebird promises using almost 2 times more memory

and

Conclusion

Node.js v8 comes with significantly improved performance of native ES2015 promises and ES2017 async functions, further boosted by the introduction of native util.promisify.

Answer 2

try/catch received TurboFan optimizations in commit 9aac80f for V8 5.3 (Node v7.x and above). This means that the historic statement that try/catch has bad performance is no longer true.
From V8 blog post:

In the past V8’s had difficulties optimizing the kind of language features that are found in ES2015+. For example, it never became feasible to add exception handling (i.e. try/catch/finally) support to Crankshaft, V8’s classic optimizing compiler. This meant V8’s ability to optimize an ES6 feature like for...of, which essentially has an implicit finally clause, was limited. Crankshaft’s limitations and the overall complexity of adding new language features to full-codegen, V8’s baseline compiler, made it inherently difficult to ensure new ES features were added and optimized in V8 as quickly as they were standardized.

Fortunately, Ignition and TurboFan (V8’s new interpreter and compiler pipeline), were designed to support the entire JavaScript language from the beginning, including advanced control flow, exception handling, and most recently for...of and destructuring from ES2015. The tight integration of the architecture of Ignition and TurboFan make it possible to quickly add new features and to optimize them fast and incrementally.

---

try/catch in an async function is just syntatic sugar over a Promise .then and .catch methods, and performance is therefore determined by the underlying Promise implementation. Bluebird claims to have better performance than native Promise implementations, so theoretically - if what Bluebird claims is true - you'll achieve better try/catch performance by overriding the native Promise implementation with Bluebird's Promise implementation.
For example, in Node: const Promise = require("bluebird"), or global.Promise = require("bluebird") to override it globally.

Note however that this might change in the future, as the original Promise implementation was in JavaScript, but has recently been re-implemented in C++ as can be tracked in bug #5343.