I'm not using UiBinder or Gin.
I am using GWT RPC, I18N and ImageResource.
I have approximately:
- 100 methods across several ClientBundles returning an ImageResource.
- 700 I18N methods spread over about 30 interfaces (my initial 2 permutations
were for the default locale)
- for GWT RPC, I have about 40 RPC methods. One of those is used for the
command pattern and has a hierarchy of about 70 request classes that can be
passed to it.
My initial VM args were:
-Xmx1024M -Xss8M
This is running on linux 64 bit, with enough spare RAM that it never used any
swap space.
After changing to your suggested VM args, the initial compile was 62s (instead
of 3 minutes), then compiling from the browser took 18.4s, 16.8s, 17.0s, 17.4s,
15.4s, 16.8s, 16.0s
I did add a "-Dgwt.speedtracerlog=/tmp/superdevmode.json" argument, but no file
was produced.
HTH
Paul
On 08/06/12 22:12, Ray Cromwell wrote:
Hmm, that's still not where we'd like to be. Our design goal is< 10s.
Are you using UiBinder, Gin, ImageResource, I18N, GWT RPC? I'm
wondering if one of the generators may or may not have an issue with
incremental compilation.
This may not do anything, but try it anyway, add these JVM flags
-Dgwt.persistentunitcache
-Dgwt.persistentunitcachedir=/tmp
-XX:MaxPermSize=512M
-Xmx2048m
Also add -Dgwt.speedtracerlog=/tmp/superdevmode.json
And send me the resulting file after a few recompile runs. This may
give me a hint as to which parts of the compiler are taking too long.
-Ray
On Fri, Jun 8, 2012 at 2:03 PM, Paul Robinson<[email protected]> wrote:
I've just tried SuperDevMode for the first time. I have around 250KLOC, of
which around 200KLOC are translated to javascript.
The code server reported 3 minutes for the initial compile (with 2
permutations), then 37 seconds for the first compile from the browser, and
then consistently 18-19 seconds thereafter.
Paul
On 08/06/12 21:38, Ray Cromwell wrote:
I just checked again, one of the internal apps we are trying
SuperDevMode against has about 400,000 lines of code and combines in
about 7-8 seconds. So maybe your app has 6x as much code? If not, it
gives us a clue that perhaps there's some other edge condition causing
the compile to be slow.
-Ray
On Fri, Jun 8, 2012 at 12:09 PM, Ray Cromwell<[email protected]>
wrote:
How big is your app? (KLOC) Internally, we'd had success with<10s
refresh on some fairly largish apps. I'm wondering if something else
isn't going on. Note that the first compile usually takes long, but
subsequent ones are faster. Are you using UiBinder? One issue could be
generators using too much time.
On Fri, Jun 8, 2012 at 11:21 AM, Jens<[email protected]> wrote:
Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.
https://code.google.com/p/google-web-toolkit/source/detail?r=11031
Thanks for the info. I had the same problem but now it works. Now lets
hope
the compilation process will become a lot faster in the future. A single
permutation of our app compiles on the code server in ~45 seconds and
thats
not really acceptable during development compared to the "classic"
DevMode.
-- J.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
