Hacker News Reader

Comment by killercup | Hacker News Reader

Title should probably be "V8 Optimization Killers".

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.

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.

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.

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

Just a cursory glance at browser stats seems to show chrome as the most popular which would make sense. I highly doubt anyone using internet explorer is coming to SO.

Chrome on iOS doesn't even use V8.

Chrome on iOS is Safari in a box.

Umm, why not? I use IE 11 in day-to-day usage and as my primary dev target. Chrome is god awful on my machine (it sucks on high DPI displays, has terrible touch support, worse/slower UI responsiveness and animations due to single UI thread, etc). I only use it for compat testing.

Also nice that IE doesn't still require prefixes for established things like transition/transform. If only Chrome and others would get around to implementing other useful CSS3 features that IE has (like grid) we might be able to actually use them some day.

It would be nice to see more information about optimizing for IE and Firefox's JS engines, but to be fair, V8 accounts for a large percent of browser JS and all of Node.js as well.

Node.js is the answer, here. Most stuff you do on the client (outside webgl and game calculations) shouldn't be impacted heavily by these kinds of optimization snafus. But if you're trying to get your server to be as performant as possible, these can really kill you if you snafu naïvely.

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.

Well V8 is the one that matters most. More users use Chrome then Firefox, so it's more important on the client-side. And server-side javascript is probably going to be running on V8. Node.js, Google's scripting platforms, all run V8.

It's like complaining if a C++ performance article only tested with GCC. Sure, there's other compilers out there, but that's the big one.

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.

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

We changed the title to say "V8".

Reply on news.ycombinator.com