V8 Optimization Killers • Hacker News Board

Re: V8 Optimization Killers

#41

Post by Alphasite_ » Wed, Jun 25, 2014, 3:10 PM UTC

phpnode wrote: post #6

btown wrote: post #2

An excellent overview! A bit worrying that using an object as a hash table and iterating over its keys using ForIn would prevent optimization - I had always thought that this was a common use case that would be well-supported by the optimizer! I suppose in that case, if you need fast reads of all keys and can afford slower writes, you could maintain an array of the keys at insertion time and just loop through that?

`for ... in` is a relatively slow construct anyway, the faster option (a lot more verbose) is: var keys = Object.keys(obj), length = keys.length, key, i; for (i = 0; i While this is not exactly the same as for..in, it usually behaves how you'd expect and is significantly faster for a couple of reasons: 1. In a for..in loop the engine must keep track of the keys already iterated over, whereas in the fast version we ca…

Is that (#2) defined behaviour, or is it undefined? Because iirc, other languages disallow it for similar reasons.

Re: V8 Optimization Killers

#42

Post by evilpie » Wed, Jun 25, 2014, 3:13 PM UTC

phpnode wrote: post #28

ekmartin wrote: post #27

Earlier quoted context omitted.

I think minifiers use the former because it's shorter, and thus requires less space.

the other benefit is that `void 0` cannot be overwritten in sloppy mode, whereas you can do something crazy like this: undefined = 'lol';

No you can't. You can do something like function(undefined) {}, but the global 'undefined' is non-writable and non-configurable.

Re: V8 Optimization Killers

#43

Post by netghost » Wed, Jun 25, 2014, 3:21 PM UTC

jwmerrill wrote: post #25

binarymax wrote: post #5

Really great! Some notes that popped out for me are that to always cache the .length property for any array or arguments: function doesntLeakArguments() { var args = new Array(arguments.length); for(var i = 0; i becomes: function doesntLeakArguments() { var len = arguments.length; var args = new Array(len); for(var i = 0; i And also, if you've got a switch statement with more than 128 cases, you've probably got bigge…

This used to be good advice, but I'm pretty sure that the modern engines all perform this optimization for you now.

Try this benchmark out: http://jsperf.com/fastest-array-loops-in-javascript/56

It looks like you're right, very right unless there's something else going on in the perf tests.

Re: V8 Optimization Killers

#44

Post by ahoge » Wed, Jun 25, 2014, 3:28 PM UTC

evilpie wrote: post #42

phpnode wrote: post #28

Earlier quoted context omitted.

the other benefit is that `void 0` cannot be overwritten in sloppy mode, whereas you can do something crazy like this: undefined = 'lol';

No you can't. You can do something like function(undefined) {}, but the global 'undefined' is non-writable and non-configurable.

That's an ES5 change. With ES3, you can overwrite NaN, Infinity, and undefined.

Re: V8 Optimization Killers

#45

Post by general_failure » Wed, Jun 25, 2014, 3:31 PM UTC

phpnode wrote: post #6

btown wrote: post #2

An excellent overview! A bit worrying that using an object as a hash table and iterating over its keys using ForIn would prevent optimization - I had always thought that this was a common use case that would be well-supported by the optimizer! I suppose in that case, if you need fast reads of all keys and can afford slower writes, you could maintain an array of the keys at insertion time and just loop through that?

`for ... in` is a relatively slow construct anyway, the faster option (a lot more verbose) is: var keys = Object.keys(obj), length = keys.length, key, i; for (i = 0; i While this is not exactly the same as for..in, it usually behaves how you'd expect and is significantly faster for a couple of reasons: 1. In a for..in loop the engine must keep track of the keys already iterated over, whereas in the fast version we ca…

Object.keys() does not need to malloc() ?

Re: V8 Optimization Killers

#46

Post by phpnode » Wed, Jun 25, 2014, 3:34 PM UTC

netghost wrote: post #43

jwmerrill wrote: post #25

Earlier quoted context omitted.

This used to be good advice, but I'm pretty sure that the modern engines all perform this optimization for you now.

Try this benchmark out: http://jsperf.com/fastest-array-loops-in-javascript/56 It looks like you're right, very right unless there's something else going on in the perf tests.

There's something going on with the perf tests - most of that code is being optimised away, in one case I got over a billion cycles per second. The trick to these things is writing code which cannot be optimised away, like returning Math.random() from a function and using the return value to increment another variable.

Re: V8 Optimization Killers

#47

Post by autnecare » Wed, Jun 25, 2014, 3:43 PM UTC

PSeitz wrote: post #31

I created a jsperf to measure a hashtable-like object with for-in/Objekt.keys The performance differs only with 50%, I expected more actually. Am I doing something wrong? http://jsperf.com/for-in-with-hashtable-like-object

I guess it depends on what you're intent is;

http://jsperf.com/for-in-with-hashtable-like-object/4

Re: V8 Optimization Killers

#48

Post by jonpacker » Wed, Jun 25, 2014, 3:45 PM UTC

rockdoe wrote: post #40

Igglyboo wrote: post #32

Earlier quoted context omitted.

Just a cursory glance at browser stats seems to show chrome as the most popular which would make sense. I highly doubt anyone using internet explorer is coming to SO.

Chrome on iOS doesn't even use V8.

Chrome on iOS is Safari in a box.

Re: V8 Optimization Killers

#49

Post by BrandonLive » Wed, Jun 25, 2014, 4:05 PM UTC

Igglyboo wrote: post #32

Touche wrote: post #4

Earlier quoted context omitted.

I'm really sick of these recent JavaScript performance related posts that only talk about V8.

Just a cursory glance at browser stats seems to show chrome as the most popular which would make sense. I highly doubt anyone using internet explorer is coming to SO.

Umm, why not? I use IE 11 in day-to-day usage and as my primary dev target. Chrome is god awful on my machine (it sucks on high DPI displays, has terrible touch support, worse/slower UI responsiveness and animations due to single UI thread, etc). I only use it for compat testing.

Also nice that IE doesn't still require prefixes for established things like transition/transform. If only Chrome and others would get around to implementing other useful CSS3 features that IE has (like grid) we might be able to actually use them some day.

Re: V8 Optimization Killers

#50

Post by kretor » Wed, Jun 25, 2014, 4:15 PM UTC

Instead of avoiding all those optimization killers, a much more higher impact approach is to fix this in the V8 project. You not only make your own code faster, you make thousands if not millions of pieces of code faster.