[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
I'll make the change to remove all of the numVisit++ references. then
I'll add a test for the OptimizerStats class and fix up to pass
checkstyle before requesting a code review.
http://gwt-code-reviews.appspot.com/841801/diff/1/4
File dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/4#newcode127
dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java:127:
numVisits++;
On 2010/09/07 19:56:38, scottb wrote:
Ouch.. this is going to be a huge maintenance pain. And it doesn't
*really*
account for all the nodes this visitor visits... it only counts nodes
we wrote a
specific override for here. Can we rethink this?
Yes, it would be a pain.What I was trying to measure here is the
number of nodes that the optimizer thought was interesting. The ratio
of optimizer effecitiveness would be to compare this number to the
number of nodes that the optimizer modified.
In some cases we override the visit() methods in order to cut off the
tree traversal. It doesn't seem fair to count those as 'interesting'
nodes.
Scott and I talked offline about this and decided to try changing
JModVisitor to count calls to visit() and measure any performance
impact.
http://gwt-code-reviews.appspot.com/841801/diff/1/4#newcode1839
dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java:1839:
stats.recordModified(deadCodeVisitor.getNumMods()).recordVisits(deadCodeVisitor.numVisits);
On 2010/09/07 19:56:38, scottb wrote:
I have a sort of data nit here. The way the data is displayed, it
tends to make
you think that the visitor modified, say, 21 out of 800 nodes. But
when you
loop like this, what really happens is that you modify 11/200, then
9/200, then
1/200, then 0/200. If we're not going to break each one out as a
child stat,
then it seems more useful to know the general size of the whole AST
going in, if
that's possible, than to see an inflated number of visit counts that
depends
entirely on how many times the loop executed internally.
How about I pull out and increment the number modified from the each
visit, then populate the number visited after the last step?
http://gwt-code-reviews.appspot.com/841801/diff/1/9
File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/9#newcode275
dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java:275:
madeChanges();
On 2010/09/07 19:56:38, scottb wrote:
Shouldn't the ctx.replaceMe() do this?
Yup, Done.
http://gwt-code-reviews.appspot.com/841801/diff/1/9#newcode472
dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java:472:
madeChanges();
On 2010/09/07 19:56:38, scottb wrote:
Same here.
Done.
http://gwt-code-reviews.appspot.com/841801/diff/1/10
File dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/10#newcode29
dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java:29: private
ListOptimizerStats children = new ArrayListOptimizerStats();
On 2010/09/07 19:56:38, scottb wrote:
This being used right now? It's kind of odd that you can query
mods/visits
programmatically, but you can't iterate over the children from the
outside.
Makes you think mods/visits should actually include child counts as
well, the
way it's formulated.
The only way to see anything about the children is printing.
That's what it is used for - along with the didChange() function. I'll
make the use of children orthogonal.
http://gwt-code-reviews.appspot.com/841801/diff/1/10#newcode43
dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java:43: return
numMods;
On 2010/09/07 19:56:38, scottb wrote:
Seems kind of strange... how can I modify without visiting?
This is to catch the use of the API where you instantiate it with
boolean constructor. Its an artifact now that I have updated all the
optimizers to actually keep counts. I'll remove it.
http://gwt-code-reviews.appspot.com/841801/diff/1/10#newcode52
dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java:52: public
OptimizerStats(String name, boolean didChange) {
On 2010/09/07 19:56:38, scottb wrote:
What's this overload for? (Need javadoc.)
An interim step where I was able to quickly return Optimizer stats by
initializing it with the old didChange boolean. I'll remove it.
http://gwt-code-reviews.appspot.com/841801/diff/1/12
File
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/12#newcode248
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java:248:
stats.recordModified(
updated to only count visits from the analysis visitor and the first
pass of the substitute parameter visitor.
http://gwt-code-reviews.appspot.com/841801/diff/1/13
File dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
(right):
[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
http://gwt-code-reviews.appspot.com/841801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
The updated patch simply iterates of the tree to count the nodes at the beginning of each loop. In my tests, the cost of that walk is 5ms on a small program, whereas the cost of the biggest optimizer is 100ms, so I feel comfortable leaving it in there. Here is the new trace output: Pass 1: 1.83 % ( 14354/784752) Pruner: 3.19 % ( 3134/ 98094) Finalizer: 2.49 % ( 2446/ 98094) MakeCallsStatic: 0.82 % ( 801/ 98094) TypeTightener: 1.24 % ( 1220/ 98094) MethodCallTightener: 0.07 % (73/ 98094) DeadCodeElimination: 1.29 % ( 1269/ 98094) MethodInliner: 5.47 % ( 5367/ 98094) SameParameterValueOptimizer: 0.04 % (44/ 98094) Pass 2: 1.08 % ( 2690/250200) Pruner: 3.50 % ( 1095/ 31275) Finalizer: 0.01 % ( 4/ 31275) MakeCallsStatic: 0.58 % ( 182/ 31275) TypeTightener: 0.85 % ( 266/ 31275) MethodCallTightener: 0.10 % (30/ 31275) DeadCodeElimination: 0.52 % ( 164/ 31275) MethodInliner: 3.00 % ( 939/ 31275) SameParameterValueOptimizer: 0.03 % (10/ 31275) Pass 3: 0.34 % ( 632/185408) Pruner: 1.05 % ( 243/ 23176) Finalizer: 0.00 % ( 0/ 23176) MakeCallsStatic: 0.13 % (29/ 23176) TypeTightener: 0.27 % (62/ 23176) MethodCallTightener: 0.00 % ( 1/ 23176) DeadCodeElimination: 0.25 % (59/ 23176) MethodInliner: 1.00 % ( 232/ 23176) SameParameterValueOptimizer: 0.03 % ( 6/ 23176) Pass 4: 0.31 % ( 524/168184) Pruner: 0.31 % (65/ 21023) Finalizer: 0.00 % ( 0/ 21023) MakeCallsStatic: 0.00 % ( 1/ 21023) TypeTightener: 0.04 % ( 8/ 21023) MethodCallTightener: 0.00 % ( 1/ 21023) DeadCodeElimination: 0.85 % ( 179/ 21023) MethodInliner: 1.28 % ( 269/ 21023) SameParameterValueOptimizer: 0.00 % ( 1/ 21023) Pass 5: 0.07 % ( 106/162992) Pruner: 0.31 % (63/ 20374) Finalizer: 0.00 % ( 1/ 20374) MakeCallsStatic: 0.00 % ( 1/ 20374) TypeTightener: 0.01 % ( 2/ 20374) MethodCallTightener: 0.00 % ( 0/ 20374) DeadCodeElimination: 0.09 % (19/ 20374) MethodInliner: 0.10 % ( 20/ 20374) SameParameterValueOptimizer: 0.00 % ( 0/ 20374) Pass 6: 0.03 % (44/157832) Pruner: 0.11 % (22/ 19729) Finalizer: 0.00 % ( 0/ 19729) MakeCallsStatic: 0.00 % ( 0/ 19729) TypeTightener: 0.05 % ( 9/ 19729) MethodCallTightener: 0.00 % ( 0/ 19729) DeadCodeElimination: 0.07 % (13/ 19729) MethodInliner: 0.00 % ( 0/ 19729) SameParameterValueOptimizer: 0.00 % ( 0/ 19729) Pass 7: 0.01 % (23/156168) Pruner: 0.03 % ( 5/ 19521) Finalizer: 0.00 % ( 0/ 19521) MakeCallsStatic: 0.01 % ( 2/ 19521) TypeTightener: 0.00 % ( 0/ 19521) MethodCallTightener: 0.00 % ( 0/ 19521) DeadCodeElimination: 0.00 % ( 0/ 19521) MethodInliner: 0.08 % ( 16/ 19521) SameParameterValueOptimizer: 0.00 % ( 0/ 19521) Pass 8: 0.00 % ( 3/156232) Pruner: 0.01 % ( 2/ 19529) Finalizer: 0.00 % ( 0/ 19529) MakeCallsStatic: 0.00 % ( 0/ 19529) TypeTightener: 0.01 % ( 1/ 19529) MethodCallTightener: 0.00 % ( 0/ 19529) DeadCodeElimination: 0.00 % ( 0/ 19529) MethodInliner: 0.00 % ( 0/ 19529) SameParameterValueOptimizer: 0.00 % ( 0/ 19529) Pass 9: 0.00 % ( 0/156040) Pruner: 0.00 % ( 0/ 19505) Finalizer: 0.00 % ( 0/ 19505) MakeCallsStatic: 0.00 % ( 0/ 19505) TypeTightener: 0.00 % ( 0/ 19505) MethodCallTightener: 0.00 % ( 0/ 19505) DeadCodeElimination: 0.00 % ( 0/ 19505) MethodInliner: 0.00 % ( 0/ 19505) SameParameterValueOptimizer: 0.00 % ( 0/ 19505) DataflowOptimizer: % ( 5/ 0) http://gwt-code-reviews.appspot.com/841801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
I went back and removed my style nit comments to focus on the
substantive stuff. Manually tracking the number of visits in every
visitor, and how that data is used, are my primary concerns.
http://gwt-code-reviews.appspot.com/841801/diff/1/4
File dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/4#newcode127
dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java:127:
numVisits++;
Ouch.. this is going to be a huge maintenance pain. And it doesn't
*really* account for all the nodes this visitor visits... it only counts
nodes we wrote a specific override for here. Can we rethink this?
http://gwt-code-reviews.appspot.com/841801/diff/1/4#newcode1839
dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java:1839:
stats.recordModified(deadCodeVisitor.getNumMods()).recordVisits(deadCodeVisitor.numVisits);
I have a sort of data nit here. The way the data is displayed, it tends
to make you think that the visitor modified, say, 21 out of 800 nodes.
But when you loop like this, what really happens is that you modify
11/200, then 9/200, then 1/200, then 0/200. If we're not going to break
each one out as a child stat, then it seems more useful to know the
general size of the whole AST going in, if that's possible, than to see
an inflated number of visit counts that depends entirely on how many
times the loop executed internally.
http://gwt-code-reviews.appspot.com/841801/diff/1/9
File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/9#newcode275
dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java:275:
madeChanges();
Shouldn't the ctx.replaceMe() do this?
http://gwt-code-reviews.appspot.com/841801/diff/1/9#newcode472
dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java:472:
madeChanges();
Same here.
http://gwt-code-reviews.appspot.com/841801/diff/1/10
File dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java
(right):
http://gwt-code-reviews.appspot.com/841801/diff/1/10#newcode29
dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java:29: private
ListOptimizerStats children = new ArrayListOptimizerStats();
This being used right now? It's kind of odd that you can query
mods/visits programmatically, but you can't iterate over the children
from the outside. Makes you think mods/visits should actually include
child counts as well, the way it's formulated.
The only way to see anything about the children is printing.
http://gwt-code-reviews.appspot.com/841801/diff/1/10#newcode43
dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java:43: return
numMods;
Seems kind of strange... how can I modify without visiting?
http://gwt-code-reviews.appspot.com/841801/diff/1/10#newcode52
dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java:52: public
OptimizerStats(String name, boolean didChange) {
What's this overload for? (Need javadoc.)
http://gwt-code-reviews.appspot.com/841801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
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)
Re: [gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
Eric, I think that you are on the right track by trying to measure the effectiveness of each optimization -- even if we need to more data to increase the accuracy. On Fri, Sep 3, 2010 at 6:02 AM, Eric Ayers zun...@google.com wrote: 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.comwrote: 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)
[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
On 2010/09/03 03:38:46, zundel wrote: Just a general comment, if you want to get even more granularity, look at this old path of mine, which instrumented MethodInliner to give really good information on exactly how many times something was inlined vs not, and a count of the failure types, which would tell you how the optimizer is failing on certain code constructs. Here's a link: http://gwt-code-reviews.appspot.com/64813/diff/1/2 http://gwt-code-reviews.appspot.com/841801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
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
