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

61–70 of 71 posts

Re: Performance of ES6 features relative to ES5

#61

Post by fenomas »

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…

Agreed, and issues like this make me hugely suspicious of JS performance benchmarks. I'm only familiar with V8, but my experience has been that there are more or less three "tiers" of factors that affect performance:

1. whether the optimizing compiler gets used

2. random stuff that's impossible to know about unless you grab your code's internal representation and decompile it [1]

3. the raw performance of individual statements

The effects of (1) dominate (2), and the effects of (2) dominate (3). So when I see performance micro-benchmarks that purport to measure (3) without apparently paying any attention to (1) or (2), my first inclination is to assume the results are essentially random noise.

[1] E.g. whether statements get wrapped in type checks, whether an integer variable gets handled internally as a SMI (small int) or whether it keeps getting converted to a boxed Number and back. The cost of such things can easily exceed the cost of the statement you're trying to benchmark.

Re: Performance of ES6 features relative to ES5

#62

Post by acdha »

paulddraper wrote: post #55
acdha wrote: post #27

Earlier quoted context omitted.

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?

It does but the most common JITed language in existence is JavaScript, where the uncertainty is especially pronounced. For example, Python isn't [traditionally] a JITed language but most Python developers know that their code will run on CPython, which is pretty stable and you have a rough idea of which versions it'll run on, whereas something running in a browser can see huge shifts in what is an expensive or cheap operation from user to user over the course of a single day, much less release to release.

Remember when WebKit started JITing regular expressions? That changed the benchmark situation so much that some people called it cheating and not a single line of user code changed. That's not impossible in other environments – I'm sure there's been a case where a shared library update made a big difference – but it's far less common in my experience.

Re: Performance of ES6 features relative to ES5

#63

Post by Dylan16807 »

vegabook wrote: post #47

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…

Don't be so smug.

Also you're wrong. "__ faster" implies addition in many/most cases. Since you know what 1.6x is by itself, I'll let you use your math knowledge to calculate x + 1.6x.

Re: Performance of ES6 features relative to ES5

#64

Post by eltaco »

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…

You can use loose mode which doesn't use try/catch blocks

http://babeljs.io/repl/#?experimental=false&evaluate=true&lo...

Re: Performance of ES6 features relative to ES5

#66

Post by rgrove »

spankalee wrote: post #46
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.

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.

Thanks for the link! That post definitely makes it sound like try/catch optimizations are on the way. I didn't know it was being worked on.

Re: Performance of ES6 features relative to ES5

#67

Post by bzbarsky »

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.

It's not impossible at all. try/catch in the non-throwing case is fast in both Firefox (SpiderMonkey) and IE (Chakra); I'm not sure what the state of things is in Safari (JavaScriptCore). In the throwing case you obviously have to do some work, but as long as that case is rare it's not a problem. Contrast with the V8 situation (which they are fixing), where simply having a try/catch in your function at all will deoptimize the function, even if an exception is never actually thrown.

Oh, and one optimization strategy for try catch is even pretty simple to describe in general terms: you need a cheap way to check whether an exception is thrown, and then after every operation that can throw (e.g. a call into the vm to a function that is allowed to throw) you check whether it did. If not, you just move along. If it did, you jump to an out of line path that does cleanup and callstack unwinding. The devil, as usual, is in the details.

Re: Performance of ES6 features relative to ES5

#68

Post by dang »

vegabook wrote: post #47

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…

Please don't post uncivil comments to Hacker News.

We detached this subthread from https://news.ycombinator.com/item?id=11204967 and marked it off-topic.

Post reply on HN