Hacker News Reader

Comment by awalGarg | Hacker News Reader

Note that async functions always return native promises. So if you like your fast or sugary promise libraries, you can't make async functions return those promises. You are stuck with the native promises, which, as of now, are pretty slow in almost all engines in comparison to the heavily optimized promise library bluebird.

I guess we should just hope that engines will optimize their own promise implementations. This might not matter much in front-end apps, but absolutely does for Node apps.

Other than that, I believe it is time JS gets: 1. An actually useful try/catch (with pattern matching on the catched errors) 2. Standard stack traces across all engines

Those two will really help async/await.

View on HN

https://kpdecker.github.io/six-speed/

According to this, native Promises are 2x faster than Bluebird in Chrome and 7-8x faster in Safari, and the same speed as Bluebird in Firefox and Edge. I remember a yearish ago they were slow, but that appears to no longer be true.

Part of the work Igalia did in 2016 was to improve compatibility and performance of native Promise. It's a constantly moving target. If you single out v8, they're constantly improving the JIT, evolving the architecture, while individual features (e.g. generators, Promise) continually get optimized on top of those underlying engine changes. Lots of people talk about performance in absolute terms, but what is really needed is a proper performance test suite for individual features and a kangax style[1] browser/engine version perf chart (edit: like the link you posted, duh!) to track it over time similar to the more general AWFY[2]. I guess the main issue is that the test suite needs to be more accepted by the browser teams as a de-facto standard?

[1]: http://kangax.github.io/compat-table/es6/

[2]: https://arewefastyet.com/

>I guess we should just hope that engines will optimize their own promise implementations.

Firefox/Spidermonkey have just ported their Promises completely to C++ [1] which will help performance and enable future optimisations.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313049

The funny part is that they _used_ to be completely in C++ (as part of Gecko, not SpiderMonkey). Then they were rewritten to be part of SpiderMonkey, and various bits were made self-hosted in the process. This turned out to be slower than doing it all in C++, for various reasons, some of which might be Gecko-specific (e.g. support for security wrappers).

But in general, optimizing promises as specified in ES6 is _really_ hard. There's all sorts of work that the spec says should be done which is typically unnecessary (for example, did you know that every time you resolve a Promise with another Promise, that causes creation of a _third_ Promise that no one cares about) but can be observed from script in various ways (e.g. by messing with @@species) so are very hard to optimize out. Promises are also very gc-intensive as specified....

This is one of those cases (iterators being the other poster child) where the usual "yeah, people will just write complicated enough engines with complicated enough JITs to make this all perform OK enough" attitude of the ECMA committee is a bit annoying.

the cool kids are already moving to observables anyway :)

Reply on news.ycombinator.com