I've sent the speed tracer file directly to you.
Also, I have some http GET requests that the code server cannot find (quite
reasonably). It would be nice if it could delegate anything it can't find to
the external tomcat/jetty.
It's also objecting to some of the characters in the URL of some of my http GET
requests. Is it possible c.g.g.dev.codeserver.WebServer's safe filename pattern
could be an optional argument?
Thanks,
Paul
On 08/06/12 22:53, Ray Cromwell wrote:
Opps, sorry, the speedtracer log is always on anyway. Look in the
super-dev-mode work dir, e.g.
/tmp/gwt-codeserver-*/modulename/speedtracer.html
I think the issue might be that I18N generators don't implement
IncrementalGenerator, and so they run every compile, even if nothing
in your interfaces or property files changed. We are talking about
having perhaps two buttons in the UI, "Compile" and "Run Generators
and Compile", or maybe checkbox. Then, we'd run the generators once on
the first compile, and subsequent recompiles would not re-run them.
Except when people are editing css, images, or i18n interfaces, they
can then do a full 'regenerate and recompile'. Later when all of the
standard GWT generators are taught to behave better it would be needed
less and less.
On Fri, Jun 8, 2012 at 2:41 PM, Paul Robinson<[email protected]> wrote:
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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
