[gwt-contrib] Re: Reduces size of the compile report (soyc) for large projects with many (issue1171801)

2010-12-01 Thread zundel

To justify the complexity of this change, here is the dramatic
difference in the leftoverStatus and splitStatus reports:

before:
-rwxrwxrwx 1 zundel nonconf 149M Nov 24 14:37 leftoverStatus-0.html
-rwxrwxrwx 1 zundel nonconf   33M Nov 24 14:37 splitStatus-0.html

after:
-rw-r- 1 zundel eng  1.5M Dec  1 03:34 leftoverStatus-0.html
-rw-r- 1 zundel eng 1.5M Dec  1 03:34 splitStatus-0.html

The overall report size was reduced from 690M to 472M.

http://gwt-code-reviews.appspot.com/1171801/show

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


[gwt-contrib] Re: Reduces size of the compile report (soyc) for large projects with many (issue1171801)

2010-12-01 Thread kprobst

LGTM, but please not my comments...

SOYC is becoming smart!! One thing I'm wondering is whether we have a
good way of making sure we still get the right information everywhere
(the smarter it gets, the harder it gets to follow in some sense, e.g.,
one-character function names, etc.).  There's SoycTest, but when I wrote
it, it was pretty empty (just checking for the existence of a file or
two).  Do you think medium term it would be worth it to add some tests
to that to make sure we're getting the right entries in the different
categories?



http://gwt-code-reviews.appspot.com/1171801/diff/1/3
File dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
(right):

http://gwt-code-reviews.appspot.com/1171801/diff/1/3#newcode115
dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java:115:
public void freeze() {
I've been trying to come up with a way in which you would not have to
call freeze() and still be safe.  I don't have a good solution -- my
only gripe here is that if you forget to call freeze(), you won't get
any values.  Seems like the only way to get around this is to call
freeze whenever something is put in the builder, but that seems very
overheady.  The only other thing I can come up with is for frozen and
builder to actually be the same thing (so do an in-place reordering when
you call freeze -- also see my comment below).  In that case, if you
forget to call freeze, you still have access to the data, just not in an
optimal way. Do you have any other brilliant ideas?

http://gwt-code-reviews.appspot.com/1171801/diff/1/3#newcode126
dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java:126: }
What happens if your count has more than 8 digits?

http://gwt-code-reviews.appspot.com/1171801/diff/1/3#newcode131
dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java:131:
builder = null;
So the only thing I'm wondering is why you're not just using a
TreeMapString, Integer (for frozen) and sorting it by value rather
than key (in the comparator that you give it).  Would that not get you
around having to create the valus TreeMap?

http://gwt-code-reviews.appspot.com/1171801/show

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


[gwt-contrib] Re: Reduces size of the compile report (soyc) for large projects with many (issue1171801)

2010-12-01 Thread zundel

http://gwt-code-reviews.appspot.com/1171801/show

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


[gwt-contrib] Re: Reduces size of the compile report (soyc) for large projects with many (issue1171801)

2010-12-01 Thread Eric Ayers
On Wed, Dec 1, 2010 at 1:49 PM,  kpro...@google.com wrote:
 LGTM, but please note my comments...

 SOYC is becoming smart!! One thing I'm wondering is whether we have a
 good way of making sure we still get the right information everywhere
 (the smarter it gets, the harder it gets to follow in some sense, e.g.,
 one-character function names, etc.).  There's SoycTest, but when I wrote
 it, it was pretty empty (just checking for the existence of a file or
 two).  Do you think medium term it would be worth it to add some tests
 to that to make sure we're getting the right entries in the different
 categories?


I forgot to answer this. I agree an automated test would be good.   I
don't have any great ideas on how to do it, but here are some
thoughts:

 - load a report page in HTML unit and start walking the DOM
 - perform some sort of automated broken link analysis on the report.

filed an issue

http://code.google.com/p/google-web-toolkit/issues/detail?id=5697
-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors