Performance of ES6 features relative to ES5 • Hacker News Board

Re: Performance of ES6 features relative to ES5

#41

Post by idbehold » Tue, Mar 01, 2016, 7:24 PM UTC

mrcarrot wrote: post #36

dcwca wrote: post #32

Earlier quoted context omitted.

No, the word faster means an increase by that amount. 100% faster means twice as fast. 1x faster means twice as fast. 100% as fast means no change. 1x as fast means no change. English, you subtle trickster!

I'm not sure I've ever seen anything described as being '1x' faster, without any fractional part. It's such an uncommon usage, I really don't think you can categorically declare that '1x faster means twice as fast'.

If I said A was 50% faster than B which is faster? Because it means the same as A is 0.5x faster than B.

Re: Performance of ES6 features relative to ES5

#42

Post by vegabook » Tue, Mar 01, 2016, 7:55 PM UTC

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,…

Ummm, thank you for stating the obvious. 1.6 x faster is interpreted by anybody who has ever in their lives taken any undergraduate course even remotely related to mathematics, let alone anybody who has ever coded even the most simplistic mathematical algorithm, as meaning 60% faster. The fact that you have to specify this is ridiculous and sadly, serves to confirm stereotypes about front end coders being clueless.

For avoidance of doubt: 1 * (ie "TIMES", as stated, not PLUS) 1.6 = 1.6 = 60% greater than 1. I hope this is not controversial.

Re: Performance of ES6 features relative to ES5

#43

Post by _greim_ » Tue, Mar 01, 2016, 8:07 PM UTC

I assumed the "es6" row header refers to the engine's native implementation of the feature. In which case it should grey out "destructuring" under Node 4.2.6. But they don't, it's listed as "10x slower". What am I missing?

Re: Performance of ES6 features relative to ES5

#44

Post by coldtea » Tue, Mar 01, 2016, 8:16 PM UTC

idbehold wrote: post #41

mrcarrot wrote: post #36

Earlier quoted context omitted.

I'm not sure I've ever seen anything described as being '1x' faster, without any fractional part. It's such an uncommon usage, I really don't think you can categorically declare that '1x faster means twice as fast'.

If I said A was 50% faster than B which is faster? Because it means the same as A is 0.5x faster than B.

For "A was 50% faster than B", it could very easily be B which is faster -- and A is half its speed.

What I meant to say in my parent comment is not the use of "faster" vs "as fast" in English, but that usually in those benchmarks "Nx" means N times the speed of the baseline.

Re: Performance of ES6 features relative to ES5

#45

Post by kgr » Tue, Mar 01, 2016, 8:27 PM UTC

goldbrick wrote: post #40

rgrove wrote: post #25

Earlier quoted context omitted.

> 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.

Yes, my understanding is the problem is essentially undefined behavior as exceptions can be caught at any point in the call stack which makes it basically impossible to optimize.

Java optimizes try/catches.

Re: Performance of ES6 features relative to ES5

#46

Post by spankalee » Tue, Mar 01, 2016, 8:51 PM UTC

rgrove wrote: post #25

spankalee wrote: post #15

Earlier quoted context omitted.

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.

V8 uses Turbofan to optimize some functions that Crankshaft couldn't. As of July, `for-of` and `with` were optimized with Turbofan, but not `try-catch`: http://v8project.blogspot.com/2015/07/v8-45-release.html

Since then there's been work on Turbofan support for `try-catch`, but I can't tell if it's been shipped and enabled, so I could be wrong.

Re: Performance of ES6 features relative to ES5

#47

Post by vegabook » Tue, Mar 01, 2016, 9:35 PM UTC

The "commentariat" charge is legitimate, which is why there is a field known as "mathematics" which is unambiguous. 1.6x by anybody's non-commentariat definition is 60% faster, as anybody who has ever even scratched the surface of any mathematical, engineering, scientific, statistical or indeed, computer science discipline knows (though this is perhaps unknown to the Creative Suite crowd). This comment is completely bogus, with apologies if you don't understand. But you really should know what you don't know before posting such garbage.

Re: Performance of ES6 features relative to ES5

#48

Post by d0vs » Tue, Mar 01, 2016, 9:45 PM UTC

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,…

Thanks Captain Obvious

Re: Performance of ES6 features relative to ES5

#49

Post by freyr » Tue, Mar 01, 2016, 10:39 PM UTC

vegabook wrote: post #42

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,…

Ummm, thank you for stating the obvious. 1.6 x faster is interpreted by anybody who has ever in their lives taken any undergraduate course even remotely related to mathematics, let alone anybody who has ever coded even the most simplistic mathematical algorithm, as meaning 60% faster. The fact that you have to specify this is ridiculous and sadly, serves to confirm stereotypes about front end coders being clueless. F…

Anybody who paid attention during their undergraduate math class would know that mathematicians value clear, unambiguous language.

"1.6X faster" might be obvious in the context (or not), but "1X faster" becomes a little murky and could easily be misinterpreted as 100% faster.

Re: Performance of ES6 features relative to ES5

#50

Post by Zarel » Tue, Mar 01, 2016, 10:42 PM UTC

coldtea wrote: post #44

idbehold wrote: post #41

Earlier quoted context omitted.

If I said A was 50% faster than B which is faster? Because it means the same as A is 0.5x faster than B.

For "A was 50% faster than B", it could very easily be B which is faster -- and A is half its speed. What I meant to say in my parent comment is not the use of "faster" vs "as fast" in English, but that usually in those benchmarks "Nx" means N times the speed of the baseline.

In English, "50% faster" is unambiguously "1.5x as fast". No one would ever interpret it as meaning that B is faster.