3 ms·

> 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

by azakai 12y ago

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

sheetjs 12y ago
> 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 semantics.
- pjmlp 12y ago
  Even if you only care about V8, it would be JIT version specific.
_greim_ 12y ago
I actually don't want to memorize any list, unless it's a list of things that are inherently expensive/impossible to optimize in JS, in which case it's worthwhile. I just hate the idea of having to write all my code according to some list-of-the-week. What I want is a list that separates the always-know stuff from the engine-specific-tweaks or might-not-apply-next-year stuff.
- _greim_ 12y ago
  Actually re-reading the article, I see this: Currently not optimizable: Generator functions Functions that contain a for-of statement Functions that contain a try-catch statement Functions that contain a try-finally statement Functions that contain a compound let assignment Functions that contain a compound const assignment Functions that contain object literals that contain __proto__, or get or set declarations. Likely never optimizable: Functions that contain a debugger statement Functions that call literally eval() Functions that contain a with statement Which I now realize is sort of what I'm looking for.
- kevingadd 12y ago
  That list won't ever be accurate. The only way to know is to re-run your performance tests every time Google and Mozilla ship new releases. SpiderMonkey now optimizes a bunch of difficult cases it never optimized before; some of them seemed like they would never get optimized, but now they're fine. V8 does some nice optimizations now that weren't possible before, similarly.

by azakai 12y ago

sheetjs 12y ago

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

pjmlp 12y ago
Even if you only care about V8, it would be JIT version specific.

_greim_ 12y ago

I actually don't want to memorize any list, unless it's a list of things that are inherently expensive/impossible to optimize in JS, in which case it's worthwhile. I just hate the idea of having to write all my code according to some list-of-the-week. What I want is a list that separates the always-know stuff from the engine-specific-tweaks or might-not-apply-next-year stuff.

_greim_ 12y ago
Actually re-reading the article, I see this: Currently not optimizable: Generator functions Functions that contain a for-of statement Functions that contain a try-catch statement Functions that contain a try-finally statement Functions that contain a compound let assignment Functions that contain a compound const assignment Functions that contain object literals that contain __proto__, or get or set declarations. Likely never optimizable: Functions that contain a debugger statement Functions that call literally eval() Functions that contain a with statement Which I now realize is sort of what I'm looking for.
kevingadd 12y ago
That list won't ever be accurate. The only way to know is to re-run your performance tests every time Google and Mozilla ship new releases. SpiderMonkey now optimizes a bunch of difficult cases it never optimized before; some of them seemed like they would never get optimized, but now they're fine. V8 does some nice optimizations now that weren't possible before, similarly.