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

11–20 of 88 posts

Re: V8 Optimization Killers

#11

Post by binarymax »

pdw wrote: post #10
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.

I understand that use case, but in my opinion it would be much cleaner (and speculating faster) to have an 256-slot array...and routing with opcodes[byte.charCodeAt(0)](); or something similar.

Re: V8 Optimization Killers

#12

Post by kateperry »

my roomate's sister-in-law earned $14851 last month. she is getting paid on the laptop and moved in a $499100 house. All she did was get blessed and put to work the clues exposed on this web site ,,,,,,,, ,,,,,,,, WWW.MAX43.COM

Re: V8 Optimization Killers

#16

Post by Touche »

hawkice wrote: post #9
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 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 don't know why you are bring up asm.js.

Re: V8 Optimization Killers

#17

Post by d0ugie »

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 deoptimization hell when rendering? And would it be a safe guess that whatever mod_pagespeed does to a page's javascript resources is less likely to result in this hell than these other tools? Thanks.

Re: V8 Optimization Killers

#18

Post by simonster »

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.

Here's a page with some performance tips for both V8 and SpiderMonkey: https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-M.... Unfortunately given the pace at which JS engines move it may be slightly out of date.

Re: V8 Optimization Killers

#19

Post by arcatek »

binarymax wrote: post #11
pdw wrote: post #10

Earlier quoted context omitted.

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.

I understand that use case, but in my opinion it would be much cleaner (and speculating faster) to have an 256-slot array...and routing with opcodes[byte.charCodeAt(0)](); or something similar.

Function calls are expensive if they are not optimized. However, the same is true for switch/case trees, and even for JIT'd code (dynamically created functions) ...

In the Javascript world, "Your Mileage May Vary" truly is a motto.

Re: V8 Optimization Killers

#20

Post by rplnt »

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.

It's like searching for any js problem on SO and almost every single question containing top answer with response along the lines "use jquery".
Post reply on HN