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

81–88 of 88 posts

Re: V8 Optimization Killers

#81

Post by jkrems »

Nitramp wrote: post #70
jkrems wrote: post #60

Earlier quoted context omitted.

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

Not if the function is inlineable or an intrinsic (console.log will likely be either), which is the most basic trick of any JIT. Unless you can specifically measure caching the length is faster, I wouldn't do it. Most of the time it doesn't matter anyway (won't cause a bump in performance), and even then most of the time the compiler will be able to figure it out for you.

Maybe my comment was misleading - the important part is the property read, not the `console.log`. The following code might be an infinite loop in JavaScript:

  function adder(arr, obj) {
    for (var i = 0; i

Re: V8 Optimization Killers

#82

Post by ekmartin »

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?

A native counter for-loop will always be faster: http://jsperf.com/angular-foreach-vs-native-for-loop/13

Re: V8 Optimization Killers

#83

Post by pjmlp »

sheetjs wrote: post #63
azakai wrote: post #62

Earlier quoted context omitted.

> if I memorize this particular list Please don't memorize this list. It's just for one JS engine among several, all of which are changing rapidly. For example Apple just shipped FTL, an LLVM-based JIT for Safari (so any list for Safari would have just been largely obsoleted).

> It's just for one JS engine among several If you are writing code for nodejs, none of the other engines are relevant. If the overwhelming majority of your users are using chrome, then v8-specific optimizations aren't a bad idea. On the issue of the list, most of the guidelines here apply here and in every other engine. For example, I doubt a future JS engine can optimize `arguments` abuse while preserving ES5 seman…

Even if you only care about V8, it would be JIT version specific.

Re: V8 Optimization Killers

#85

Post by esailija »

jkrems wrote: post #81
Nitramp wrote: post #70

Earlier quoted context omitted.

Not if the function is inlineable or an intrinsic (console.log will likely be either), which is the most basic trick of any JIT. Unless you can specifically measure caching the length is faster, I wouldn't do it. Most of the time it doesn't matter anyway (won't cause a bump in performance), and even then most of the time the compiler will be able to figure it out for you.

Maybe my comment was misleading - the important part is the property read, not the `console.log`. The following code might be an infinite loop in JavaScript: function adder(arr, obj) { for (var i = 0; i

V8 can inline getters and setters like it can inline normal functios.

Re: V8 Optimization Killers

#86

Post by esailija »

hcho wrote: post #36
Touche wrote: post #4

Earlier quoted context omitted.

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

I would hazard a guess that it's because the intended audience is the node js crowd. Maybe apart from games, most of this is irrelevant for browser side javascript.

Yes, it's actually a wiki page in a node.js project.

Re: V8 Optimization Killers

#87

Post by Igglyboo »

kevingadd wrote: post #75
Igglyboo wrote: post #33

Earlier quoted context omitted.

Why would the use a switch instead of a hashtable?

Good compilers optimize a switch into a jump table, which is much, much faster than a hashtable. Using a hashtable for instruction dispatch in an emulator would be utterly insane. You'd use an array (but the compiler can do a better job by generating raw asm for a jump table.)

Could you explain why it would be insane? I was under the impression that all you needed was fast lookup time.

Re: V8 Optimization Killers

#88

Post by kevingadd »

Igglyboo wrote: post #87
kevingadd wrote: post #75

Earlier quoted context omitted.

Good compilers optimize a switch into a jump table, which is much, much faster than a hashtable. Using a hashtable for instruction dispatch in an emulator would be utterly insane. You'd use an array (but the compiler can do a better job by generating raw asm for a jump table.)

Could you explain why it would be insane? I was under the impression that all you needed was fast lookup time.

A jump table is O(1). A hash table lookup is gonna be roughly O(N) for the hash + O(M) for the size of the hash bucket. Small hash tables can end up with very large buckets. Hash buckets are sometimes linked lists as well, so you pay the cost of that pointer indirection to walk the bucket. It's possible that a typical JS runtime can cache the hash value for a given string (especially literals), so that will help a bit for string keys. Integer keys might have a similar optimization.

People overestimate the performance of hash tables. It's true that they are quite fast on a modern CPU, so you get away with using them extensively in dynamic languages like JS, but they are still way way slower than a jump table or directly accessing fields at statically known offsets.

Post reply on HN