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

V8 Optimization Killers

github.com

Post reply on HN
Print view View original

1–10 of 88 posts

Re: V8 Optimization Killers

#2

Post by btown »

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?

Re: V8 Optimization Killers

#5

Post by binarymax »

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 bigger problems on your hands than v8 optimizations.

I see some things in here that I can start switching to immediately for some of my node modules.

Re: V8 Optimization Killers

#6

Post by phpnode »

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 can simply increment a counter and do a fast array lookup.

2. It's possible to add properties to the object that you're iterating within the body of the for..in statement, and these will be iterated too. Doing such a thing is obviously very rare but it's the kind of edge case the JS engine must keep track of.

Re: V8 Optimization Killers

#7

Post by phpnode »

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…

The article is "optimisation killers", you're right about caching the array length lookup check being faster, but it doesn't kill V8's ability to optimise functions like the rest of the examples do

Re: V8 Optimization Killers

#9

Post by hawkice »

Touche wrote: post #4
killercup wrote: post #3

Title should probably be "V8 Optimization Killers".

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

I think the general idea is that asm.js is both well understood and not something a human should ever generate, so why would anyone but a transpiler writer care?

Re: V8 Optimization Killers

#10

Post by pdw »

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…

Huge switches are common in the inner loop of emulators and interpreters. They tend to end up with a 256-case switch to handle the next byte in the instruction stream.
Post reply on HN