I was thinking about how keeping track of the AST size on the fly could be expensive and complicated. The simplest thing to do would be to have to add in a separate walk that just counted nodes, maybe once at the head of optimizeLoop. I wrote this dummy code earlier to measure the cost of just a walk, and it turns out that walking the tree and counting all nodes is a computationally significant amount of work - its like adding an extra optimizer. I didn't want to have too much observer effect if the change is just for statistical purposes. (but maybe I could add that walk just in the case of having tracing enabled.)
But I mis-spoke when describing my goal as tuning code size to compile time. I'm really just trying to find ways to shorten the compile time. You've mentioned a couple of times about the optimizations being quadratic cost. I want to use this feature to add an option with a "decent" amount of optimization and shave off a significant amount of the compile time. Something between draftCompile and fully optimized. The decision point to opt out of the build to could be specific to each optimizer. For example, if each optimizer declares that isn't doing "much" through a single or two consecutive passes, it might be time to throw in the towel. We could have users specify an optimization level: -O, -O2, -O3, ... like c compilers and gzip do to specify the amount of optimization desired. At the water cooler we've speculated that there might be interaction between optimizers we can predict. e.g. dead code elimination isn't going to do much if the pruner and type tightener weren't very effective on the last pass (I just made that up). Early in my investigations I was hoping that we could just stop calling some of the optimizers that aren't very effective after the first few passes, but the only visibility I had was the didChange boolean. Now we could do some statistics gathering on different apps and see if that would be worth pursuing. -Eric. On Fri, Sep 3, 2010 at 12:02 AM, Ray Cromwell <cromwell...@gmail.com> wrote: > > I think it's useful to see the amount of work done vs time spent, but I > don't think it will help automate size-tradeoffs unless you keep track of > the size of the AST as well, so that you can see roughly how much it's being > reduced each pass. Some optimizations don't really shrink the AST size, but > enable other optimizations. e.g. type tightening, finalizing, and > static-fying help method inliner, DCE, and pruner. It would be nice to > correlate, for example, with and without those tightening/staticifying > passes, how much worst the actual code-deleting passes would be, because > that's the only real way if you know they're worth it. > > Some things have an effect far down the chain, for example, static-methods > can be obfuscated better, because 'this' can't be obfuscated, so you don't > see the code-size effect symbol obfuscation, as AST size doesn't tell the > whole story. > > -Ray > > > On Thu, Sep 2, 2010 at 8:48 PM, Eric Ayers <zun...@google.com> wrote: > >> I'm looking for feedback on this proposed change, mainly, is the >> statistical information worth the added complexity? Currently, this only >> dumps out a diagnostic when you specify >> >> >> >> -Dgwt.jjs.traceMethods=com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimize >> >> on the Compiler command line. Here's a sample of what the statistical >> output looks like on a minimal GWT app: >> >> Pass 1 ---- ( 0/ 0) >> Pruner 27.94% ( 3132/ 11211) Finalizer 45.64% ( 2455/ >> 5379) MakeCallsStatic 7.94% ( 812/ 10229) TypeTightener 2.41% ( 1226/ >> 50966) MethodCallTightener 1.96% ( 70/ 3569) DeadCodeElimination 1.93% >> ( 1277/ 66324) MethodInliner 28.84% ( 5430/ 18830) >> SameParameterValueOptimizer 0.58% ( 44/ 7588) >> Pass 2 ---- ( 0/ 0) >> Pruner 12.24% ( 1089/ 8895) Finalizer 0.09% ( 4/ >> 4400) MakeCallsStatic 2.68% ( 182/ 6796) TypeTightener 0.80% ( 272/ >> 33915) MethodCallTightener 1.36% ( 32/ 2353) DeadCodeElimination 0.41% >> ( 166/ 40201) MethodInliner 9.95% ( 956/ 9609) >> SameParameterValueOptimizer 0.24% ( 14/ 5776) >> Pass 3 ---- ( 0/ 0) >> Pruner 1.79% ( 240/ 13392) Finalizer 0.00% ( 0/ >> 4036) MakeCallsStatic 0.50% ( 31/ 6221) TypeTightener 0.31% ( 62/ >> 20088) MethodCallTightener 0.05% ( 1/ 2190) DeadCodeElimination 0.20% >> ( 74/ 37391) MethodInliner 2.90% ( 250/ 8608) >> SameParameterValueOptimizer 0.11% ( 6/ 5325) >> Pass 4 ---- ( 0/ 0) >> Pruner 0.54% ( 57/ 10492) Finalizer 0.03% ( 1/ >> 3948) MakeCallsStatic 0.02% ( 1/ 6086) TypeTightener 0.05% ( 8/ >> 14660) MethodCallTightener 0.05% ( 1/ 2147) DeadCodeElimination 0.47% >> ( 173/ 36545) MethodInliner 2.07% ( 172/ 8310) >> SameParameterValueOptimizer 0.02% ( 1/ 5126) >> Pass 5 ---- ( 0/ 0) >> Pruner 0.67% ( 66/ 9896) Finalizer 0.03% ( 1/ >> 3747) MakeCallsStatic 0.02% ( 1/ 5732) TypeTightener 0.01% ( 2/ >> 13845) MethodCallTightener 0.00% ( 0/ 2012) DeadCodeElimination 0.05% >> ( 19/ 35210) MethodInliner 0.20% ( 16/ 8001) >> SameParameterValueOptimizer 0.00% ( 0/ 4976) >> Pass 6 ---- ( 0/ 0) >> Pruner 0.30% ( 22/ 7338) Finalizer 0.00% ( 0/ >> 3695) MakeCallsStatic 0.00% ( 0/ 5691) TypeTightener 0.07% ( 9/ >> 13660) MethodCallTightener 0.00% ( 0/ 2001) DeadCodeElimination 0.06% >> ( 13/ 23220) MethodInliner 0.00% ( 0/ 2638) >> SameParameterValueOptimizer 0.00% ( 0/ 4938) >> Pass 7 ---- ( 0/ 0) >> Pruner 0.10% ( 5/ 4890) Finalizer 0.00% ( 0/ >> 3688) MakeCallsStatic 0.04% ( 2/ 5690) TypeTightener 0.00% ( 0/ >> 4548) MethodCallTightener 0.00% ( 0/ 2001) DeadCodeElimination 0.00% >> ( 0/ 11605) MethodInliner 0.38% ( 20/ 5283) >> SameParameterValueOptimizer 0.00% ( 0/ 4937) >> Pass 8 ---- ( 0/ 0) >> Pruner 0.04% ( 2/ 4886) Finalizer 0.00% ( 0/ >> 3686) MakeCallsStatic 0.00% ( 0/ 5684) TypeTightener 0.01% ( 1/ >> 9093) MethodCallTightener 0.00% ( 0/ 1999) DeadCodeElimination 0.00% >> ( 0/ 11601) MethodInliner 0.00% ( 0/ 2634) >> SameParameterValueOptimizer 0.00% ( 0/ 4933) >> Pass 9 ---- ( 0/ 0) >> Pruner 0.00% ( 0/ 2443) Finalizer 0.00% ( 0/ >> 3686) MakeCallsStatic 0.00% ( 0/ 5684) TypeTightener 0.00% ( 0/ >> 4546) MethodCallTightener 0.00% ( 0/ 1999) DeadCodeElimination 0.00% >> ( 0/ 11601) MethodInliner 0.00% ( 0/ 2634) >> SameParameterValueOptimizer 0.00% ( 0/ 4933) >> DataflowOptimizer 0.46% ( 5/ 1080) >> >> I think the information is interesting on its own, but it could prove >> useful if we decide to implement a compiler option to allow users to make a >> compilation time/code size output trade off. Our current options are either >> minimal optimization or maximum possible optimization. We could probably >> cut the production compile down a bit if we had an in-between option (and >> maybe made it the default). >> >> In a couple of places, I got rid of the didChange() overload on >> JModVisitor subclasses. I know that there is a difference, I'm wondering if >> it is important. >> >> My eclipse environment is a mess - please don't bother with code >> formatting feedback until I dig myself out from under it. >> >> -Eric. >> >> On Thu, Sep 2, 2010 at 11:38 PM, <zun...@google.com> wrote: >> >>> Reviewers: scottb, robertvawter, cromwellian, >>> >>> Description: >>> RR: Add statistics to optimizers >>> >>> Updates the compiler optimizers to returns statistics about each pass >>> instead of a simple boolean. This could be used to analyze >>> the effectiveness of an individual optimizer, tune the compiler >>> for code size/ compile time trade offs, or predict the effectiveness >>> of future passes of an optimizer. >>> >>> >>> Please review this at http://gwt-code-reviews.appspot.com/841801/show >>> >>> Affected files: >>> M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java >>> M dev/core/src/com/google/gwt/dev/jjs/ast/JModVisitor.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/Finalizer.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/LongCastNormalizer.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/MethodCallTightener.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java >>> A dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java >>> M >>> dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java >>> M dev/core/src/com/google/gwt/dev/jjs/impl/gflow/DataflowOptimizer.java >>> M >>> dev/core/src/com/google/gwt/dev/jjs/impl/gflow/liveness/LivenessTransformation.java >>> M >>> dev/core/src/com/google/gwt/dev/jjs/impl/gflow/unreachable/DeleteNodeVisitor.java >>> >>> >>> >> >> >> -- >> Eric Z. Ayers >> Google Web Toolkit, Atlanta, GA USA >> >> > -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
