3 ms·
Which of these (if any) are purely incidental to the current state of the V8 project, rather than being inherently insurmountable problems for JS optimization?
by _greim_ 12y ago
Which of these (if any) are purely incidental to the current state of the V8 project, rather than being inherently insurmountable problems for JS optimization? In other words, if I memorize this particular list, what subset of my knowledge may become obsolete in a few months or years?
- bzbarsky 12y agoThe try/catch bit is definitely incidental to the current state of V8. Other JITs (e.g. SpiderMonkey) will happily handle try/catch.
- olliej 12y ago|with| makes reasoning about function behaviour extremely difficult, take: var x = 5; something.propertyOnSomething = 5 with(something) { x += propertyOnSomething } alert(x); // What is the value of x? eval() causes problems as it can introduce new variables into the local scope making it logically difficult to reason about program behaviour subsequent to the eval(), e.g. function f(x) { eval(something); return Math.sqrt(x); } What is the result of f(9)? It is possible to set things up to make these not catastrophically harm performance, but the question is whether you would rather the engineers working on these engines make uncommon (and arguably bad) things common, or make normal and frequent code fast. Any time spent working on making uncommon things fast is time not spent making other things fast.
- 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 agoEven if you only care about V8, it would be JIT version specific.
- _greim_ 12y agoI 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 agoActually 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 agoThat 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.