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

51–60 of 88 posts

Re: V8 Optimization Killers

#51

Post by kipple »

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 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

#53

Post by _greim_ »

Which of these (if any) are purely incidental to the current state of the V8 project, rather than being inherently insurmountable problems for JS optimization? In other words, if I memorize this particular list, what subset of my knowledge may become obsolete in a few months or years?

Re: V8 Optimization Killers

#54

Post by mccr8 »

binarymax wrote: post #39
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.

I can't say for arguments, but optimizing for a changing array.length in-loop must be difficult if not impossible. for(var i=0;i

Compiler optimizations are never perfect. In this case, a compiler would just assume that push could be called and not hoist the length calculation.

Re: V8 Optimization Killers

#55

Post by _greim_ »

kretor wrote: post #50

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.

I was wondering this too. I expect/hope the answer would be "we're working on it" in most cases, but I worry it would be "it simply isn't possible" in some or most scenarios.

Re: V8 Optimization Killers

#56

Post by bzbarsky »

kipple wrote: post #51
phpnode wrote: post #6

Earlier quoted context omitted.

`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 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?

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

#57

Post by bzbarsky »

sheetjs wrote: post #30
killercup wrote: post #3

Title should probably be "V8 Optimization Killers".

To be fair, many of these apply to other JS engines as well: - manipulating `arguments` should be avoided - when possible, avoid looping over the properties of an object (using `in` or `Object.keys`) In the process of optimizing for v8, you may expose other bad patterns (e.g. megamorphic functions) whose replacement will boost performance everywhere. For example, even though https://github.com/petkaantonov/deque was…

While true, some other bits of advice here (like pulling your try/catch into a separate function) are very V8-specific and may well produce _worse_ code in other implementations.

http://jsfiddle.net/G83mW/14/ has a testcase for the try/catch thing that is interesting to compare in different browsers...

Re: V8 Optimization Killers

#58

Post by bzbarsky »

_greim_ wrote: post #53

Which of these (if any) are purely incidental to the current state of the V8 project, rather than being inherently insurmountable problems for JS optimization? In other words, if I memorize this particular list, what subset of my knowledge may become obsolete in a few months or years?

The try/catch bit is definitely incidental to the current state of V8. Other JITs (e.g. SpiderMonkey) will happily handle try/catch.

Re: V8 Optimization Killers

#59

Post by PSeitz »

autnecare wrote: post #47
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

The article states "Code compiled by the optimizing compiler can easily be, say, 100x faster than the code generated by the generic compiler"

So expected a quite more than a factor of 2 ...

Re: V8 Optimization Killers

#60

Post by jkrems »

mccr8 wrote: post #54
binarymax wrote: post #39

Earlier quoted context omitted.

I can't say for arguments, but optimizing for a changing array.length in-loop must be difficult if not impossible. for(var i=0;i

Compiler optimizations are never perfect. In this case, a compiler would just assume that push could be called and not hoist the length calculation.

JavaScript is complex enough that pretty much any code inside of the loop could end up doing an array push. Even `console.log(myCompletelyUnrelatedObject.x)` (given an evil property descriptor).
Post reply on HN