JavaScript – Why Native ES6 Promises Are Slower Than Bluebird

io.jsjavascriptperformance

In this benchmark, the suite takes 4 times longer to complete with ES6 promises compared to Bluebird promises, and uses 3.6 times as much memory.

How can a JavaScript library be so much faster and lighter than v8's native implementation written in C? Bluebird promises have exactly the same API as native ES6 promises (plus a bunch of extra utility methods).

Is the native implementation just badly written, or is there some other aspect to this that I'm missing?

Best Answer

Bluebird author here.

V8 promises implementation is written in JavaScript not C. All JavaScript (including V8's own) is compiled to native code. Additionally user written JavaScript is optimized, if possible (and worth it), before compiled to native code. Promises implementation is something that would not benefit much or at all from being written in C, in fact it would only make it slower because all you are doing is manipulating JavaScript objects and communication.

The V8 implementation simply isn't as optimized as bluebird, it for instances allocates arrays for promises' handlers. This takes a lot of memory when each promise also has to allocate a couple of arrays (The benchmark creates overall 80k promises so that's 160k unused arrays allocated). In reality 99.99% of use cases never branch a promise more than once so optimizing for this common case gains huge memory usage improvements.

Even if V8 implemented the same optimizations as bluebird, it would still be hindered by specification. The benchmark has to use new Promise (an anti-pattern in bluebird) as there is no other way to create a root promise in ES6. new Promise is an extremely slow way of creating a promise, first the executor function allocates a closure, secondly it is passed 2 separate closures as arguments. That's 3 closures allocated per promise but a closure is already a more expensive object than an optimized promise.

Bluebird can use promisify which enables lots of optimizations and is a much more convenient way of consuming callback APIs and it enables conversion of whole modules into promise based modules in one line (promisifyAll(require('redis'));).

Related Solutions

Limitations of an Idealistic HTML5 Web Application

Off top of my head...

access proprietary hardware that exports its I/O by other means than a file. Be that scientific equipment, industrial machinery, or plain CD recorder and a digitizer tablet with tilt support.
only HTTP and a small family of other protocols. You can't create sockets as you wish, transferring whatever binary data you desire. That vastly limits connectivity with other systems and services.
No sane developer will create graphics-intensive game in Javascript. Broadband is not nearly comparable to DVD/HDD throughputs often needed. Support for 3D in Canvas is vastly inferior to what you get with game engines. No way to support joystick, multiple simultaneous keypresses, the open nature makes cheating easy. But primarily, the performance drop is not acceptable.
Heavy sandboxing. You won't get stuff that deeply integrates into the OS. Screenshots, antivirus, virtual drives, background tasks a'la system tray, administrative tasks etc.
can't be mission-critical. Depending on broadband at all times to run their basic software is not the preferred way most companies like to run.

LINQ Performance – Does LINQ Require More Processing Cycles and Memory?

I'd say the main weakness of this answer is less its use of Linq and more the specific operators chosen. GroupBy takes each element and projects it to a key and a value which go into a lookup. In other words, every word will add something to the lookup.

The naive implementation .GroupBy(e => e) will store a copy of every word in the source material, making the final lookup nearly as large as the original source material. Even if we project out the value with .GroupBy(e => e, e => null) we're creating a large lookup of small values.

What we would want is an operator that preserves only the needed information, which is one copy of each word and the count of that word so far. For that, we can use Aggregate:

words.Aggregate(new Dictionary<string, int>(), (counts, word) => 
{
    int currentCount;
    counts.TryGetValue(word, currentCount);
    counts[word] = currentCount + 1;
    return counts;
}

From here, there are several ways we could attempt to make this faster:

Instead of creating many strings while splitting, we could pass around structs that reference the original string and the segment that contains the word, and only copy the segment out when it turns out to be a unique key
Use Parallel Linq to aggregate across several cores then combine the results. This is trivial compared to the leg work required for doing this by hand.

Best Answer

Related Solutions

Limitations of an Idealistic HTML5 Web Application

LINQ Performance – Does LINQ Require More Processing Cycles and Memory?

Related Topic