ES6 Performance
incaseofstairs.com
incaseofstairs.com
http://mrale.ph/blog/2014/02/23/the-black-cat-of-microbenchm...
http://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.h...
Checking the tests here, the "default parameters" section shows some tests being 2000x faster than others, which sounds suspicious. Here's an es5 test case:
function fn(arg, other) {
arg = arg === undefined ? 1 : arg;
other = other === undefined ? 3 : other;
return other;
}
test(function() {
fn();
fn(2);
fn(2, 4);
});
So what OP should do, is make function return something, and then make sure that that 'something' somehow survives the test. For example, if that 'something' is a number, add it to a global variable that survives the benchmark and print that global variable at the end of the benchmark. If it is a string, maybe add the hashcode to global variable, or maybe string length. Anyways, that will force compiler to emit the code that executes the function, and the benchmark will actually execute the function.
In short, writing JS microbenchmarks that actually test what they claim to test is quite hard.
As you mentioned, micro-benchmarks are riddled with bias, and confusing results.
So putting micro-benchmarks aside and looking at ES5 / ES6 induced performance bottlenecks in actual apps, they are clearly present. (note, this is of-course limited to features actually implemented)
Unfortunately, a macro focused endeavor (only gauging full app performance) isn't as nicely actionable as the micro.
So in practice, in an attempt to produce high value but actionable feedback a hybrid approach, utilizing both micro/macro investigation yields the best results.
In addition the micro-benchmark vs optimizing compiler trap can be mitigated by investigating the intermediate and final outputs of the optimizing compiler.
Anyways, /rant.
There exist an unfortunate amount of JS performance traps, I wish where taken more seriously. Although more work, it would be quite valuable for someone to perform a root cause analysis to investigate potential bottlenecks brought to light by this post.
I disagree. JS is obviously not fast by its nature; the only reason it's fast sometimes is because modern JS engines do incredible optimizations behind the scenes. As such, for real-world performance, writing code that the engine understands how to optimize entirely dwarfs trivia like how Babel transpiled your default parameters. (Even the most microbenchmarked function will run dog-slow if the v8 optimizer bails out.) And if real-world performance is dominated by optimizability, then it follows that microbenchmarks are largely useless unless they happen to get optimized/deoptimized in the same way that your code does.
Incidentally for v8 at least, currently using any ES6 feature (even a single "const" that's never used) causes the optimizer to bail out. So any question of "ES6-induced bottlenecks" is beside the point - it doesn't matter how fast the ES6 feature is if its mere presence slows down everything else.
He's right, you're right, js performance is still, in reality, pretty sucky in certain circumstances. It's worth talking about.
I remember writing an agonisingly slow program only 2 years ago and all that I was doing was a push/unshift, which at the time was for a mandelbrot generator I was making for fun, so had a loop of a few hundred thousand. A quick change of code and it was fine, but it was bizarre to be hitting something like that when every other language that I'd written the same code in hadn't even taken a second, let alone the minutes the javascript was taking.
Microbenchmarks and relative speeds are not super useful. I'm a performance nut and I love optimizing code -- back in the day I wrote a syntax-highlighting editor that was snappy in IE6's crappy JScript engine -- but I'm not going to worry that some syntax feature is 3x or even 10x slower than assigning to a local variable (which is what, one CPU instruction?). If you're that concerned, you should be avoiding object allocations ({}) like the plague, and that is just madness except in really performance-critical sections of code (and games).
The tables need some formatting and colors would be nice, too. Instead of "slower" and "faster" it should be just a factor. So, 2x would mean that it takes twice as long and 0.5x would mean that it's twice as fast.
Also, what's the baseline? Where does that 1x come from?
As your concurrency increases, a poor promise implementation starts burning copious amount of valuable cycles, often largely due to GC pressure.
In the abstract this doesn't sound that bad, but when comparing well behaved implementations such as BlueBird, RSVP, When, ES6-Promise etc. with the current state, (July 3, 2015) native Promises, the difference is still staggering.
As for the browser, a promise is a great way to handle async and often a great abstraction around a single potentially remote entity. As more ambitious applications are created, it isn't uncommon to have thousands or tens of thousands of these remote entities. Wouldn't it be nice, if the overhead of using the promise was negligible?
Also — off topic, but I really wish they'd provided graphs, or at least given those tables some formatting love. Does anyone know of similar benchmarks that have?
Seriously though, graphs can be manipulated to look exactly how you want the user to interpret it.
/faster/ 46
/slower/ 482
These performance hits are extreme. I would never have guessed that so many of these features are taking 20-2000x speed hits.
I hope the browsers and V8 catch up soon so transpiling ES6 is no longer necessary.