Out of curiosity, which optimizer improves performance with a size increase side-effect? That might be worth exploring if the trade-off is sensible.
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) 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
