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

51–60 of 71 posts

Re: Performance of ES6 features relative to ES5

#51

Post by __david__ »

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.

Not really, that doesn't make sense. It's "0.5x the speed of b". Saying "faster" when it's really actually slower is just confusing and ungrammatical. Likewise saying "1x faster" when it's actually the same speed is gratuitously confusing.

Re: Performance of ES6 features relative to ES5

#52

Post by SquareWheel »

Zarel wrote: post #50
coldtea wrote: post #44

Earlier quoted context omitted.

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.

This confused the heck out of me as a kid. Saying something is 50% faster means the same as being 150% faster. Or 100% faster could also be 200%, depending on subtle language choices.

Very unintuitive.

Re: Performance of ES6 features relative to ES5

#53

Post by vegabook »

freyr wrote: post #49
vegabook wrote: post #42

Earlier quoted context omitted.

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.

Shut up Brezhnev. Everybody on planet America knows that 2x faster is 100% faster. Whose side are you on.

Re: Performance of ES6 features relative to ES5

#54

Post by idbehold »

__david__ wrote: post #51
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.

Not really, that doesn't make sense. It's "0.5x the speed of b". Saying "faster" when it's really actually slower is just confusing and ungrammatical. Likewise saying "1x faster" when it's actually the same speed is gratuitously confusing.

What doesn't make sense? Saying "A is 50% faster than B" is equivalent to "A is 150% as fast as B". Same goes for "A is 0.5x faster than B" which is equivalent to "A is 1.5x as fast as B".

There is a very distinct difference between "faster than" and "as fast as" which should be very clear now.

Re: Performance of ES6 features relative to ES5

#55

Post by paulddraper »

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…

It that case, what's so special about JIT?

Wouldn't that apply to any interpreted language?

Re: Performance of ES6 features relative to ES5

#56

Post by idbehold »

SquareWheel wrote: post #52
Zarel wrote: post #50

Earlier quoted context omitted.

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

This confused the heck out of me as a kid. Saying something is 50% faster means the same as being 150% faster. Or 100% faster could also be 200%, depending on subtle language choices. Very unintuitive.

I still don't see how it could be confusing.

"faster than" != "as fast as"

A is 50% faster than B == A is 150% as fast as B

Re: Performance of ES6 features relative to ES5

#57

Post by snorrah »

This makes me think of Python 2 vs 3 benchmarks for some reason, although I'm sure I'm not remembering very well.

I assume there's plenty of scope for ES6 to improve and (hopefully?) surpass ES5 in performance in many, if not all, areas?

What would be causing the large slowdowns in ES6 here? Is this a case of having features that make JS nicer to code in, but giving up some performance? Or is this more down to immature compilers not yet optimising ES6 as substantially?

Re: Performance of ES6 features relative to ES5

#58

Post by coldtea »

Zarel wrote: post #50
coldtea wrote: post #44

Earlier quoted context omitted.

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.

Again, I wasn't talking about what's it in "proper english" -- but how it's used in benchmarks.

Kevin Decker, who did the site in TFA, is a native english speaker, and yet he writes "1.5x faster" to mean baseline1.5 (and not baseline + 1.5baseline).

So clearly it's not so "unambiguous" whether you can use faster in this way or not. And in fact, I've never seen any of those benchmarks where "Nx" doesn't mean the final value is N*baseline.

Re: Performance of ES6 features relative to ES5

#59

Post by mattashii »

dagurp wrote: post #19

Why is "identical" in green and "faster" in a slightly darker green? Is es6 a library or is it the browser's implementation of ES6?

ES6 is the native implementation in the browser or JS-engine you are using, indeed.

Green is probably chosen because the same performance is nice to have with this (subjectively) better syntax. The darker shade is probably chosen because more performance is nice, as it pushes you to the newer (subjectively better) syntax.

Re: Performance of ES6 features relative to ES5

#60

Post by mc808 »

idbehold wrote: post #54
__david__ wrote: post #51

Earlier quoted context omitted.

Not really, that doesn't make sense. It's "0.5x the speed of b". Saying "faster" when it's really actually slower is just confusing and ungrammatical. Likewise saying "1x faster" when it's actually the same speed is gratuitously confusing.

What doesn't make sense? Saying "A is 50% faster than B" is equivalent to "A is 150% as fast as B". Same goes for "A is 0.5x faster than B" which is equivalent to "A is 1.5x as fast as B". There is a very distinct difference between "faster than" and "as fast as" which should be very clear now.

You're 100% right (2x right?), but I think this is one of those situations like "bimonthly", where people usually intend it to mean twice a month instead of every two months.

It's completely ambiguous with potentially significant costs for misunderstanding, but people refuse to make themselves clear, just because.

Post reply on HN