On 17 September 2012 03:35, Luke Hoban <[email protected]> wrote: > __Temporal dead zones__ > > For reference on previous discussion of temporal dead zone see [1]. > > I've expressed concerns with the performance overhead required for temporal > dead zones in the past, but we did not at the time have any data to point to > regarding the scale of the concern. > > As an experiment, I took the early-boyer test from V8 and changed 'var' to > 'let'. In Chrome preview builds with 'let' support, I saw a consistent ~27% > slowdown. That is, the 'let is the new var' mantra leads to 27% slower code > in this example for the same functionality.
Just to be clear, the V8 implementation of block scoping and 'let' has not seen any serious performance optimisation yet. So I'd take these numbers (which I haven't verified) with a large grain of salt. Also, I conjecture that the main cost for 'let' isn't the temporal dead-zone, but block allocation. In particular, a 'let' in a loop costs a significant extra if no static analysis is performed that would allow hoisting the allocation out of the loop. > However, we are aware that there are a class of dynamic checks that can be > removed by static analysis - in particular intra-procedural use before > assignment checks. We implemented these checks in a Chakra prototype, and > even with these, we still see an ~5% slowdown. I would like to understand this better. AFAICT, you don't necessarily need much static analysis. In most cases (accesses from within the same closure) the check can be trivially omitted. In addition, once you optimise based on type feedback it is also trivial to discover that the check is no longer needed in other situations. I would expect those scenarios to cover most performance-relevant programming patterns quite well. > __ Early Errors__ > > Let and const introduce a few new early errors (though this general concern > impacts several other areas of ES6 as well). Of particular note, assignment > to const and re-declaration of 'let' are spec'd as early errors. > > Assignment to const is meaningfully different than previous early errors, > because detecting it requires binding references *before any code runs*. > Chakra today parses the whole script input to report syntax errors, but > avoids building and storing ASTs until function bodies are executed [2]. > Since it is common for significant amounts of script on typical pages to be > downloaded but not ever executed, this can save significant load time > performance cost. > > However, if scope chains and variable reference binding for all scopes in the > file need to be established before any code executes, significantly more work > is required during this load period. This work cannot be deferred (and > potentially avoided entirely if the code is not called), because early errors > must be identified before any code executes. > > This ultimately means that any script which mentions 'const' will defeat a > significant aspect of deferred AST building, and therefore take a load time > perf hit. This is indeed a concern. However, I don't think 'const' is the only problem, other ES6 features (such as modules) will probably introduce similar classes of early errors. > More generally - this raises a concern about putting increasingly more > aggressive static analysis in early errors. It may, for example, argue for a > 3rd error category, of errors that must be reported before any code in their > function body executes. I agree that this is a worthwhile possibility to consider. I mentioned this idea to Dave once and he didn't like it much, but maybe we should have a discussion. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
