News for hackers. Stuff that matters.
Re:V8 Optimization Killers by btown on Wednesday June 25, 2014 @08:26AM (#7943469)
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 by phpnode on Wednesday June 25, 2014 @09:05AM (#7943618)
`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 < length; i++) {
      key = keys[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 by kipple on Wednesday June 25, 2014 @12:26PM (#7944969)
Is a plain for loop with a counter significantly faster than a forEach? With Object.keys I've been enjoying the simplicity of statements like

  Object.keys(obj).forEach(function (key) {
    console.log(obj[key]);
  }); 
but does that hamstring my performance?
Re:V8 Optimization Killers by bzbarsky on Wednesday June 25, 2014 @01:08PM (#7945291)
Your mileage will vary depending on the browser. If you really care (as in profiling identified this as a hotspot) you should measure the alternatives you're considering.

But note that in your specific case chances are the cost of a bunch of console.log() calls completely swamps the cost of either a for loop or a forEach call. console.log() has _incredibly_ complicated behavior.

Re:V8 Optimization Killers by ekmartin on Thursday June 26, 2014 @02:27AM (#7948367)
A native counter for-loop will always be faster: http://jsperf.com/angular-foreach-vs-native-for-loop/13
Re:V8 Optimization Killers by Alphasite_ on Wednesday June 25, 2014 @11:10AM (#7944424)
Is that (#2) defined behaviour, or is it undefined? Because iirc, other languages disallow it for similar reasons.
Re:V8 Optimization Killers by gsnedders on Wednesday June 25, 2014 @05:09PM (#7946773)
Adding properties is undefined in ES5 and I believe defined in ES6.

Deleting properties is guaranteed to not break iteration and deleting an as-of-yet unvisited property causes it to never be visited.

Re:V8 Optimization Killers by general_failure on Wednesday June 25, 2014 @11:31AM (#7944563)
Object.keys() does not need to malloc() ?
Re:V8 Optimization Killers by kevingadd on Wednesday June 25, 2014 @08:03PM (#7947458)
Keys is an alloc. That is not 'faster'.