On Thu, Sep 23, 2010 at 4:04 PM, Chris Conroy <[email protected]> wrote:
> Out of curiosity, which optimizer improves performance with a size increase > side-effect? That might be worth exploring if the trade-off is sensible. I believe that MethodInliner (java) and JsInliner could take a one line function and stick the body in several places in the code, leading to an overall larger output. See optimizeLoop() in JavaToJavaScriptCompiler.java for the list of optimizers that run. > How does setting the number of passes to 3 affect optimizations that don't > have an effect on code size? (I know this is harder to measure, but it's > worth thinking about since that's essentially a hidden dimension on this > graph) > Optimizers run serially, one after the other and there are interdependencies between the changes made by one optimizer and the potential for new optimizing by one that previously ran. For example, the Pruner is limited to pruning parameters for static methods only (I'm reading the comment here, hope its not out of date). There is another optimizer that runs later that tries to make methods static. Turning on statistics in the optimizationLoop reveals that sometimes an optimizer 'unlocks' part of the tree that the other optimizer can make a significant change on... but relative to the overall size of the tree, I haven't seen anything large. One thing that setting optimization to less than full is likely to do is to tickle some bugs or "optimizations" in the rest of the code (JavaScript tree optimizers or code generation) that expect the AST to be fully optimized. I've found a minor one at http://gwt-code-reviews.appspot.com/897803/showand I'm sure there are others out there. -Eric. > On Thu, Sep 23, 2010 at 3:55 PM, Eric Ayers <[email protected]> wrote: > >> On Thu, Sep 23, 2010 at 3:48 PM, Chris Conroy <[email protected]> wrote: >> >>> Why does the compiled size increase from 8 to 9? That would seem to >>> indicate a bug with the optimizer in that step. >>> >> >> Optimizers don't just reduce code size - they also attempt to improve >> performance. >> >> >>> On Thu, Sep 23, 2010 at 3:41 PM, Eric Ayers <[email protected]> wrote: >>> >>>> The attached graph shows an analysis of code size to compile time for >>>> building a large application. The code size is the total number of bytes >>>> output for .cache.js files for all permutations added together. >>>> >>>> Somewhere between passes 2 to 4 is a "sweet spot", where further >>>> optimization passes appear to be returning only marginal improvements. At >>>> 3 optimization passes, Another way to verify that besides just the code >>>> size metric is to look at the statistics I added in a week ago that show >>>> how >>>> much the tree changes on each pass. When we looked at the same >>>> application, >>>> Changes were measured in the thousands on the first pass or two, then >>>> trickled down into the tens in later passes. >>>> >>>> Previously, I had another implementation of this feature where the >>>> DataflowOptimizer and SameParameterValueOptimizer were automatically turned >>>> off until level 6 or higher (you can flip these off with a separate command >>>> line flag). In that case, code size was nearly the same, and compile time >>>> was 220 seconds at optimization level 3. >>>> >>>> full optimization: 300s >>>> 3 passes only: 250s >>>> 3 passes - aggressive optimizations: 220s >>>> >>>> -Eric. >>>> >>>> On Thu, Sep 23, 2010 at 3:32 PM, <[email protected]> wrote: >>>> >>>>> Reviewers: scottb, fabbott, Lex, >>>>> >>>>> Description: >>>>> Adds a way to tune the optimization level in steps from >>>>> draft optimize to full optimization (the current default) >>>>> >>>>> Preliminary testing shows that optimization level '3' >>>>> can give almost as good code size results (within 5%) >>>>> as full optimization, with about 20% reduction in compile time. >>>>> >>>>> >>>>> Please review this at http://gwt-code-reviews.appspot.com/915802/show >>>>> >>>>> Affected files: >>>>> M dev/core/src/com/google/gwt/dev/Precompile.java >>>>> M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java >>>>> M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java >>>>> M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java >>>>> M dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerDraftCompile.java >>>>> A dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerOptimize.java >>>>> D dev/core/src/com/google/gwt/dev/util/arg/OptionDraftCompile.java >>>>> A dev/core/src/com/google/gwt/dev/util/arg/OptionOptimize.java >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Eric Z. Ayers >>>> Google Web Toolkit, Atlanta, GA USA >>>> >>>> -- >>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>>> >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> >> >> >> >> -- >> Eric Z. Ayers >> Google Web Toolkit, Atlanta, GA USA >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
