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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
