Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance of ES6 features relative to ES5

kpdecker.github.io

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Performance of ES6 features relative to ES5

#21

Post by rraval »

yoklov wrote: post #17

More than just these, even innocuous features such as `let` and `const` over `var` cause a substantial performance decrease in V8 (but not SpiderMonkey). I do a lot of one-off demos, that I mostly write in ES6 these days. I don't have a demonstration of pure `let` vs `var`, but if you change Babel to JavaScript in this one (and click run), you'll see a fairly substantial performance decrease in Chrome for this demo (…

There is a recent v8-users mailing list thread on this exact topic. Here's one possible explanation on perf differences between `let` and `var`: https://groups.google.com/d/msg/v8-users/hsUrt4I2D98/ELsfO1e...

Re: Performance of ES6 features relative to ES5

#22

Post by berdario »

stymaar wrote: post #14

The results given by this benchmark are bothering me because they do not fit with what I've seen in production. For example, the `for-of-array` is transpiled by babel to something that has 2 nested try/catch blocks, and unfortunately, V8 has a nasty deoptimisation when dealing with these, even if no exception is ever thrown. This deopt led to a several orders of magnitude slowdown compare to a simple `for` loop in Go…

I'm not a frontend developer but... is it still truly necessary to transpile stuff like for-of ?

It's supported by every desktop browser on the market, modulo some bugs (like inability to iterate over HTMLCollection and co. on Chrome)... as long as you only need to use it for arrays, things might work quite fine

Re: Performance of ES6 features relative to ES5

#23

Post by rictic »

berdario wrote: post #22
stymaar wrote: post #14

The results given by this benchmark are bothering me because they do not fit with what I've seen in production. For example, the `for-of-array` is transpiled by babel to something that has 2 nested try/catch blocks, and unfortunately, V8 has a nasty deoptimisation when dealing with these, even if no exception is ever thrown. This deopt led to a several orders of magnitude slowdown compare to a simple `for` loop in Go…

I'm not a frontend developer but... is it still truly necessary to transpile stuff like for-of ? It's supported by every desktop browser on the market, modulo some bugs (like inability to iterate over HTMLCollection and co. on Chrome)... as long as you only need to use it for arrays, things might work quite fine

According to caniuse, 12% of web users in the US are on IE 11, which doesn't support for-of.

Re: Performance of ES6 features relative to ES5

#24

Post by pluma »

berdario wrote: post #22
stymaar wrote: post #14

The results given by this benchmark are bothering me because they do not fit with what I've seen in production. For example, the `for-of-array` is transpiled by babel to something that has 2 nested try/catch blocks, and unfortunately, V8 has a nasty deoptimisation when dealing with these, even if no exception is ever thrown. This deopt led to a several orders of magnitude slowdown compare to a simple `for` loop in Go…

I'm not a frontend developer but... is it still truly necessary to transpile stuff like for-of ? It's supported by every desktop browser on the market, modulo some bugs (like inability to iterate over HTMLCollection and co. on Chrome)... as long as you only need to use it for arrays, things might work quite fine

Two words:

Internet Explorer.

Unless you're a startup and don't have to give a damn about what browsers your users use, IE marketshare is just too big to ignore. And depending on your audience, IE can mean anything from IE11 all the way back to IE8.

Theoretically IE is irrelevant now that Microsoft has started publicly killing it off, but you'd be surprised at the number of corporate users that are still on Windows XP (or maybe Vista/7) running IE 8 and 9.

Of course evergreen browsers are less of a problem but amazingly a lot of the same users who are stuck with IE also manage to have extremely outdated versions of Firefox.

Re: Performance of ES6 features relative to ES5

#25

Post by rgrove »

spankalee wrote: post #15
stymaar wrote: post #14

The results given by this benchmark are bothering me because they do not fit with what I've seen in production. For example, the `for-of-array` is transpiled by babel to something that has 2 nested try/catch blocks, and unfortunately, V8 has a nasty deoptimisation when dealing with these, even if no exception is ever thrown. This deopt led to a several orders of magnitude slowdown compare to a simple `for` loop in Go…

Chrome doesn't have an interpreter, it has baseline and optimizing compiler. Also, I think try/catch preventing optimization was fixed. Still your point could stand, or additionally there could be many optimizations that interfere with such simple micro benchmarks, turning all or parts of them into no-ops. If this is happening in ES5 and not ES6, the results could be drastic. I suspect this is what's happening with s…

> Also, I think try/catch preventing optimization was fixed.

Do you have a source for this? Try/catch deopts still bubble up in my Chrome profiling, so it seems like they're still a problem.

Re: Performance of ES6 features relative to ES5

#26

Post by pjmlp »

white-flame wrote: post #2

The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. New features pursue correctness, then as their place in the JITs mature interesting new approaches will change their speed characteristics later. Things like contrasting the speed of various ways of iterating an array are all semantically equivalent, and…

That applies to any language implementation.

C compilers nowadays praised for speed used to generate worse code than junior Assembly developers on home micros.

Re: Performance of ES6 features relative to ES5

#27

Post by acdha »

paulddraper wrote: post #20
white-flame wrote: post #2

The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. New features pursue correctness, then as their place in the JITs mature interesting new approaches will change their speed characteristics later. Things like contrasting the speed of various ways of iterating an array are all semantically equivalent, and…

> The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. How in the world is that specific to JIT? Have you never heard of a Sufficiently Smart Compiler?

The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the new version.

Re: Performance of ES6 features relative to ES5

#28

Post by aschampion »

venning wrote: post #9

Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline , but is reported as "1.6x faster". I know this seems like semantics,…

This is the convention when talking about speedup in software. 1x speedup means identical time.

[1] https://en.wikipedia.org/wiki/Speedup

Re: Performance of ES6 features relative to ES5

#29

Post by dragonwriter »

acdha wrote: post #27
paulddraper wrote: post #20

Earlier quoted context omitted.

> The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. How in the world is that specific to JIT? Have you never heard of a Sufficiently Smart Compiler?

The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the new…

> The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the new version.

While the release of a new AOT compiler version might not affect the performance characteristics of your application without an active choice to recompile, the release of updates to any OS components your application interacts with, may, in much the same way that a new web browser or JVM version would. The only way you get immunity from that is to bundle the whole software stack running on the bare metal as your "app", rather than relying on lower-level software that may change independently.

Re: Performance of ES6 features relative to ES5

#30

Post by coldtea »

venning wrote: post #9

Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline , but is reported as "1.6x faster". I know this seems like semantics,…

>Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed".

Isn't this always the case with such comparisons? One is meant to multiple initialValue by e.g. 1.6 (hence the "x", for multiple), not calculate initialValue + 1.6*initialValue.

Post reply on HN