Live data from Hacker News

V8 Optimization Killers

github.com

21–30 of 88 posts

Re: V8 Optimization Killers

#21
post #9
post #4

Earlier quoted context omitted.

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?

I'm not sure why you're talking about asm.js (I guess you're implying that asm.js is the only Gecko-specific optimization?), but I just want to note that I find it pretty hard to find good documentation about how to code with it.

The "not something a human should ever generate" doesn't seem like a right statement : before a transpiler can generate this kind of code, a human has to understand it.

Re: V8 Optimization Killers

#22
I wonder if there is any way to check the optimization status in the browser? It would be awesome to have a chrome audit that parsed through all of the functions in a js file and told you the optimization status of each and why.

Re: V8 Optimization Killers

#23
post #17

My team's developers, who are in a Firefox-only setting (so no V8 to consider), use every optimization/squishing trick they can find on github - grunt, browserify, uglifyjs etc - thinking that the smaller the number of javascript resources and the smaller those files are the faster the pages will not just download but also render. Is it probable that SpiderMonkey and other engines suffer from forms of this deoptimiza…

The only size-related optimization that I can think of is that V8 doesn't inline functions (but does optimize them) when they are more than X characters long, comments included.

I'm not sure about SpiderMonkey, but they may very well use this kind of optimization too. However, I would guess that Uglifying files should not increase execution speed for any noticeable amount.

Re: V8 Optimization Killers

#24

I wonder if there is any way to check the optimization status in the browser? It would be awesome to have a chrome audit that parsed through all of the functions in a js file and told you the optimization status of each and why.

[deleted]

Re: V8 Optimization Killers

#25

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.

Re: V8 Optimization Killers

#26

I wonder if there is any way to check the optimization status in the browser? It would be awesome to have a chrome audit that parsed through all of the functions in a js file and told you the optimization status of each and why.

Not the friendliest program but http://mrale.ph/irhydra/1/ can display all sorts of intermediate representations spit out by v8

Re: V8 Optimization Killers

#27
post #15

Which is better `undefinedVar === void 0` or `typeof undefinedVar === 'undefined'`? here says: http://www.2ality.com/2013/04/check-undefined.html void 0 is safe.

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

Re: V8 Optimization Killers

#28
post #15

Which is better `undefinedVar === void 0` or `typeof undefinedVar === 'undefined'`? here says: http://www.2ality.com/2013/04/check-undefined.html void 0 is safe.

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

Re: V8 Optimization Killers

#29
post #17

My team's developers, who are in a Firefox-only setting (so no V8 to consider), use every optimization/squishing trick they can find on github - grunt, browserify, uglifyjs etc - thinking that the smaller the number of javascript resources and the smaller those files are the faster the pages will not just download but also render. Is it probable that SpiderMonkey and other engines suffer from forms of this deoptimiza…

It's a good question but minification shouldn't cause runtime performance issues. Keep in mind that these are mostly micro optimizations when running outside a large loop. If you go from 1 mil ops per sec to 20 mil ops per sec your user won't see a difference unless the code is being run many times over.

Re: V8 Optimization Killers

#30

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 developed and tuned for v8, it is still much faster than alternatives in other engines.

Post reply on HN