GWT 1.5 - Compiler is new too slow

[Mikael Grev]

Hello and congrats to the 1.5 RC. Support for Java 5 is excellent and
I am excited.

I have one problem though and this might turn out to be a showstopper
for me. In 1.4.62 compiling the GWT client part took approximately
five seconds. Same code now take 35 seconds to compile. This is too
slow for me since I tend to code and run a lot.

I have just about 2000 lines in the client code and give the compiler
512MB to play with. It is using both cores on 100%.

I guess this is due to the new and cool optimizations in the compiler.
Not sure how easy this is to solve for you but maybe a switch to
disable the optimizations?

Please advice if you will not do anything about the compiler speed
since I will probably have to revert back to 1.4.62 if so. :(

Cheers,
Mikael Grev

Macbook Pro 2,4GHz, 4GB Mem. Leopard with all updates. Java 5.0 and
Java 6.0.

[rjcarr]

This is bad news ... my compile on 1.4.62 takes a solid 30+ seconds
and it is about all I can handle. If this even doubles it will be a
problem. Here's to hoping your problem is unique ... no offense. :)

[Samyem Tuladhar]

I have a fairly large code base in GWT 1.4 and it takes about 32
seconds to compile my module. With 1.5RC1, it took 7.5 minutes. I
didn't get much warnings about what may be causing such a big
difference in compile time but what 1.5 took is beyond acceptable in
my project.

GWT insiders may have some hints on why compiling is so slow with the
1.5. Any ideas?

Thanks,

[dape...@gmail.com]

My code base is large as well. It takes 10 minutes,triple slower than
1.4. And do your guys get any errors on RPC calls? My code seems lost
some response from RPC call only on RC1

Cheers,
www.wibokr.com

[Mikael Grev]

I should also mention that this is of course the compilation to
Javascript. I use -noserver since I need to serve up some images.

I couldn't make it work in hosted mode in 1.4.62. Is there anything
new that could make the internal tomcat to be used? I use IDEA and I
know that was par of the problem.

Cheers,
Mikael

[Thomas Broyer]

On 29 mai, 20:09, Mikael Grev <mikael.g...@gmail.com> wrote:
> Hello and congrats to the 1.5 RC. Support for Java 5 is excellent and
> I am excited.
>
> I have one problem though and this might turn out to be a showstopper
> for me. In 1.4.62 compiling the GWT client part took approximately
> five seconds. Same code now take 35 seconds to compile. This is too
> slow for me since I tend to code and run a lot.

If you're using the GWTShell (even with -noserver, except if you're
doing much GWT-RPC...), you don't have to compile each time you want
to run the code (and you don't even have to re-run the GWTShell; just
press F5 or the Refresh button and you're done).

Have you switched to Java 5 generics? (replacing @gwt.args with Java
type parameters)

> I have just about 2000 lines in the client code and give the compiler
> 512MB to play with. It is using both cores on 100%.
>
> I guess this is due to the new and cool optimizations in the compiler.
> Not sure how easy this is to solve for you but maybe a switch to
> disable the optimizations?

-XdisableAggressiveOptimization ;-)

[rusty]

I think there is already a case to cover this:
http://code.google.com/p/google-web-toolkit/issues/detail?id=2347

It's marked as being for 1.5...so I find it weird that it's no in the
first Release Candidate?

[stuckagain]

Haha,

What are you guys complaining about :-) I'm typically waiting 20
minutes when compiling my project :-D. It would be very nice if they
found a way to better use multicore/multiprocessor systems. I read
that Java 6 is now going multicore when compiling as well, that would
be sweet!

But ofcourse, I'm not yet complaining:
- I see a big speed improvement in hosted mode compared to 1.4.
Startup time is a loot quicker!
- I still need to migrate to generics & annonations, but it's too much
work at this time, other requirements (finish up this release with
1.4).
- I do see some issues in our application with some RPC methods not
working anymore. But I already found some issues in the application,
which before was not really giving a problem and now it does. The
other problems I'm seeing is in our GWT-RPC to SessionBean servlet
because the RPC internals have changed a bit.

Only a small part of my application I can not test in hosted mode
because I am using an Applet for certain functionality and applets
don't work in hosted mode.

David

> > -XdisableAggressiveOptimization ;-)- Hide quoted text -
>
> - Show quoted text -

[Samyem Tuladhar]

Hopefully with the next release of 1.5, the compile time is as fast,
or faster, than 1.4. Also I am despetately waiting for the "lazy
loading" feature to be implemented into GWT sometime soon.

> > > >slowfor me since I tend to code and run a lot.

[npoi...@gmail.com]

One tip for speeding up the javascript compilation when in development
is to target a single browser, using the property user.agent in
module.gwt.xml.

Also, a verbose LogLevel can really slow down the compilation, make
sure the console does not log everything.

[Jeremy Cohen]

Same here - the GWT 1.5 RC1 compile is magnitudes slower than 1.4 ( ~3 mins compared to ~45s in GWT 1.4 ). Additionally the startup in hosted mode is also extremely slow in GWT 1.5. It's to a degree of not being usable for a large project. For now I'm going to stay with GWT 1.4 and hope that there are some performance improvements before GWT 1.5 final.

Just curious if the GWT team have run performance tests with GWT 1.5? Do you have a real world large project that you test and compare the performance of 1.5 with 1.4?

Jeremy

[Antonio Leonforte]

We have a quite large project and it already takes 3 minutes to
compile with GWT 1.4. This means that GWT 1.5 is simply not an option
for us, I'm afraid. We cannot wait 20 minutes each time we compile...

>> One tip for speeding up the javascript compilation when in development is to target a single browser, using the property user.agent in module.gwt.xml.

What if you wanted to target just two browsers ?

Antonio.

[npoi...@gmail.com]

> What if you wanted to target just two browsers ?

It would be nice but I don't think its possible to target two
browsers. It's one or all.

You could target one browser when developping (FF for example) and
sometimes compile for all browser (or IE) to see if it works
correctly.


On May 30, 12:55 pm, Antonio Leonforte <antonio.leonfo...@fhoster.com>
wrote:

[NN]

funny that 1.5 slower compare 1.4

my project is not big one but notice extra time compare 1.4..weird to
start with

[stuckagain]

Hi,

Well, the idea is that most of your development can be done using
hosted mode. So you do not need to recompile to JavaScript.
Now unfortunately I seem to have a problem running in hosted mode. It
just crashes with a outofstack:0 message or it just crashes completely
and I end up in the JavaScript debugger.

Some of my RPC services can no longer be instantiated for some reason,
it worked just fine in 1.4.62.
I have the impression that RPC has even more problems with a limited
stack in IE6.

David

On May 30, 6:55 pm, Antonio Leonforte <antonio.leonfo...@fhoster.com>
wrote:

[Fred Sauer]

Have you increased you heap size?
e.g.
   -Xmx1024m

--
Fred Sauer
fr...@allen-sauer.com

[danael]

Just adding myself to the list of people noticing the slow compilation
time. I tested the GWT 1.5 source code last week and I had this same
problem.
I had changed my code to java 5,

- I switched to Java 5 generics (replacing @gwt.args with Java type
parameters)
- Used the new generic RPC calls
- Used for each loops and used autoboxing
- Removed IsSerializable
- I am using <set-property name="user.agent" value="gecko"/> to
restrict the compilation to just one agent.

in GWT 1.4 takes around 40sec to compile and in that GWT1.5 it took
7.5minutes.
I have not yet tested the RC1 version since it takes couple of days to
migrate my large code to 1.5 and the last time I did, it compiled but
never run, no warning, no error, no alerts being displayed even on the
first line of the code...nothing...just blank page resulting in a
frustrating rol back to GWT 1.4 :)

Regards and thank you guys for the hard work. Good luck.

[Fred Sauer]

Besides the usual hints already suggested, there are some JVM tuning options which may alleviate the pain:

• Take a 1/2 hour to determine the optimal settings for your project, which may be different from the optimal settings for someone else's project. Time more than one GWT compilation for each option, ignoring the first compile, and preferably averaging a few iterations.
• Repeat this process when your project grows/shrinks significantly, or there are other specific aspects of your project which have changed significantly.
• Note, results may differ with a different class of machine, or machine with a different architecture. Repeat tests as necessary.

Specific stesp to make your project compile faster:

1. Install the latest Java 6 (currently u6). You can still compile 1.5 source, and produce 1.5 bytecode. I've seen Java 6 beat Java 5 (GWT) compile time by 25%. In Eclipse change your default installed JRE to Java 6 (Window -> Preferences -> Java -> Installed JREs), but set your GWT project to use 1.5 source and produce 1.5 compatible byte code (Project -> Properties -> Java Properties -> Java Compiler).

2. Increase the max (and min) heap size. You can try different values, but "-Xms1024m -Xmx1024m" works well for many projects. The biggest win is provided by "-Xmx1024m", but there is a slight additional gain from "-Xms1024m".

3. If you have a small project, the client VM works best for GWT compiles. For larger projects (which take longer to compile), the server VM tends to be faster overall. Compile your project with both "-client" and "-server", and compare. Which VM is the default depends on whether the JVM considers your machine a server class machine: http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html

4. By adding "-verbose:gc" you can get an idea of the amount of garbadge collection taking place. You might compare "-XX:+UseParallelGC" and "-XX:+UseConcMarkSweep" (suitable for multi core systems) compile times. In practice I've not seen an advantage in altering the collector for GWT compiles on my projects, but your results may differ. The collector can make a huge difference on N-way server class machines (with N preferably > 2). So, on your J2EE server give "-XX:+UseConcMarkSweep" a whirl. You might be surprised. Note of caution: usefulness of GC advise is often short lived. Also, there's no such thing as a GC setting which always speeds things up (if there was, Sun would bake it into their VM). Finally, what settings are optimial may depend on load characteristics, your source code, the JVM version your are running, what architecture you are on, and what external influence exists. Having read that, be practical: if it makes your code compile faster, use it. Just remember to check back later and make sure that settings is still the right choice.

5. Cross polinate: be sure to update your IDE, your compile/shell scripts, and ant/maven/whatever builds, or whatever else you compile with.

6. Reply back with your findings!

HTH
Fred

--
Fred Sauer
fr...@allen-sauer.com

[Gaetan Zoritchak]

Hi,

The compilation time is one of our concern because of the size of our
application.

Currently our strategy is the following :

1. We use the presentation model pattern to organize our client code.
This pattern allows us to create a lot of small client applications
limited to the current developments. When we work on the design or
layout the client application doesn't use any RPC interface. We build
the full client application only when it is really needed before
releasing.

2. We limit the compilation to the user.agent "gecko1_8" which is the
best for development time thanks to firebug.

My 2 cents,
Gaetan Zoritchak

[Gaetan Zoritchak]

I forgot one point we didn't test yet but that should provide an
interesting solution.

GWT 1.5 allows to compile each module separately and then include each
module with a separate <script> tag in the html page. Dividing a big
application in such modules should allow to compile only what is under
development.

did somebody try this solution?

Gaetan Zoritchak

[USNaviguide.com]

It seems to me that adding http requests for the convenience of the
developer is contrary to "rule #1" for GWT, the user's experience will
suffer. Also, it may be the resulting Javascript would be bloated by
dividing up the application into modules. Caveat: GWT newbie.

-John Coryat

http://maps.huge.info

http://www.usnaviguide.com

[Fred Sauer]

Gaetan,

While that would create smaller chunks of code to compile, with each individual compile not take too long, you will find that the end user experience will suffer. Shared code among the modules will be duplicated in each compiled output. Startup overhead will multiple. Overall download size will increase, and in some cases more importantly, number of HTTP round trips will increase.

The fact that GWT does a single monolithic compilation was a very conscious decision. This allows the GWT compiler to perform all sorts of optimizations that are not possible in a Java VM because which classes are loaded at run time is not known in advance. In short: whenever possible, perform only a single GWT compilation; you loose a LOT of benefits if you don't do this.

Having said that, it is possible to have two entirely uncoordinated teams work on different GWT projects and have both deployed to a single web page. This might make sense for an intranet web portal, in which case the impact of additional downloads, HTTP requests, and so on is limited in scope, and offset by the convenience of independent deployment, compilation, etc.

Do note that you have multiple entry points in one module, and have multiple pieces of code which are *logically* independent, which could even be compiled separately during development, but for production deployment get compiled in a single GWT deployment.


Hope that helps and makes sense.

Cheers
Fred

--
Fred Sauer
fr...@allen-sauer.com

[Gaetan Zoritchak]

Fred,

I haven't been clear. We make a lot of small app only for the
development process. When we release a new version of the application
or for bigger tests we compile the entire application in one script.

Working like that saves a lot of time and avoid interuptions during
the development phase.

Cheers,
Gaetan

The smaller apps allows us to quicky launch what we're working on

> On Sun, Jun 1, 2008 at 8:03 AM, Gaetan Zoritchak <g.zoritc...@gmail.com>

> f...@allen-sauer.com

[Miguel Méndez]

Do you get any warnings/errors when trying to instantiate your RPC service?  Also, why do you suspect an RPC/stack size issue on IE6?

--
Miguel

[timothytoe]

For those of you who are working mostly in hosted mode, how quickly
can you make a code change and test it?

One of my favorite things about writing in JavaScript is that there is
no compilation time. I just make the change, save the code, and
refresh the browser.

GWT is interesting, and maybe I'll try it, but I hate to go back to a
development cycle that includes compilation.

One thing I've considered is writing my own library to use in my
projects. Someone mentioned that they've ported jQuery to Java w/ GWT
and that it's faster than native jQuery. Anyone using GWT for this-'n'-
that but still writing code in JavaScript as well? I prefer loose and
dynamic languages, but I'm willing to do a bit of Java for a few
things if the compiler really does produce faster code than I'm likely
to write.

[Mark Renouf]

Hosted mode is very bearable. Although the same steps are involved,
Expect it to be a lot faster than a full compilation. This is because
hosted mode will only re-analyze parts of your app that have changed
(ie: which class files have been reloaded).

To give an idea of relative difference, my tiny app I'm working on now
takes about 35s to fully compile to js, it takes about 20s to load
within the GWT shell the first time, but reloading takes about 5
seconds if small changes have been made.

This is one key area the GWT team recognized and the goal is to make
the normal dev cycle as fluid as possible, so I expect focus will be
made to keep that time down as much as possible. There is talk of some
changes that could drastically increase the speed of hosted mode but
those are further down the road.

[Fred Sauer]

On Mon, Jun 2, 2008 at 4:10 AM, Gaetan Zoritchak <g.zor...@gmail.com> wrote:

Fred,

I haven't been clear. We make a lot of small app only for the
development process. When we release a new version of the application
or for bigger tests we compile the entire application in one script.

Working like that saves a lot of time and avoid interuptions during
the development phase.

Cheers,
Gaetan

Perfect!

--
Fred Sauer
fr...@allen-sauer.com

[rusty]

@timothytoe: I've been using GWT for well over a year now, and have
gone through many stages. First was elation, I was a swing programmer
by trade that had only just started web development, and already hated
javascript/JSP's/cross browser stuff with a passion so GWT was right
up my alley.

A year on though I've come to see GWT as a specialist tool. Maybe I
can make a lame analogy? To me it's like a hammer drill. If you've
ever tried drilling through concrete/brick with an ordinary cordless
or corded drill, then you know it's damn hard. Sure you can do it, but
a hammer drill is the tool that makes it easy. So I see everything
from raw javascript to javascript wrappers like jquery etc like the
normal drills. They are awesome for small to medium jobs, that you're
not trying to do anything really amazing in. For these jobs it would
be silly to use a hammer drill, sure you can, but the overheads and
bulkiness of it make it impractical.

Without the analogy: GWT is a pain in the butt for small things. You
have to compile the damn thing, get all the XML in just the right
place, set up your transfer objects if you want to do RPC and let's
face it hosted mode (on the mac at least) is slow and clunky. Then
there's the fact that if you work with other people, you have to
explain all it's intricacies to them. Javascript goes with web
programming, so most people know it, JAVA doesn't necessarily, so the
chances are the rest of your team don't know it. Sure the refresh is
cool, but it doesn't hold a candle to a normal browser refresh for
standard javascripty stuff. For things that you just want to use
ordinary AJAX on you're better off going with something else. JQuery
seems to be the flavour of the month for that stuff. When you want to
do mind blowing AJAX though, GWT comes into it's own. For these kind
of jobs all the downsides don't seem that important at all, because
what you get is fast, small, cross browser javascript code with all
the benefits that a JAVA app has in maintenance over javascript.
That's where GWT shines, and where I think you'd have to be an idiot
not to use it. As the things you're trying to do get less complex
though, it becomes a moot point - in this case you ask yourself is the
overhead needed to work with GWT really needed for what I'm trying to
do.

Hope that's not too long and makes sense. I've seen people take up GWT
and build awful apps, apps that could have been much slicker had they
stuck with web technologies and not tried to turn their app into a
'desktop like' app. I've also seen people do some awesome stuff in
GWT, I mean truly awesome, stuff that you'd normally only be able to
pull off in flash, but better because it's not flash.

Rusty

[NN]

man everything is so so slow.. kind of piss** on new version.

I just feel like dumping GWT in trash can.. even sample apps
"Showcase" takes so much time to compile if you want to see
something..

also it has some kind of problem if module.html file has error..dammm
it just show HTML even if they are not perfect. I will do whatever I
want with HTML it is not GWT problem...

[Carl Scott]

I know one of the new strong points about GWT 1.5 is the optimizations
it makes in the compile process now. That said, has anyone tried
using the compiler with the optimizations turned off? Is that
possible? Do the slowness problems still exist in this context?

Thanks!

--
Carl Scott
Software Developer, Solertium Corporation

[Isaac Truett]

I've heard there's a -XdisableAggressiveOptimization flag, but I've
never used it. Searching the forum would probably turn up something.

[Sumit Chandel]

Hi everyone,

Thanks for reporting the issues you've experienced with compilation and hosted mode startup times. We're making the problem a priority and really want to get to the bottom of the slowdown and were wondering if anyone who experiences slowdowns could report them on Issue #2347 for compiler slowness and Issue #2293 for hosted mode slowness to help the team track the info.

Issue #2347 - Compiler slowness:
http://code.google.com/p/google-web-toolkit/issues/detail?id=2347

Issue #2293 - Hosted mode slowness:
http://code.google.com/p/google-web-toolkit/issues/detail?id=2293

If you are experiencing slowdowns, could you report it on the appropriate issue with the following information:

1) What have you tried to speedup the compilation process (any of the tips that other members have posted in this thread). One of the causes of the slowdown problem that we've verified is extra debug info being printed to the hosted mode shell because of all the warnings that are generated for non-1.5 compliant code. While this in itself is a problem we need to solve, turning off the -logLevel DEBUG is one way to speed up hosted mode startup.

2) What is the difference in compilation / hosted mode startup times you're observing between 1.4 and 1.5 RC?

Thanks for your help on this. Hopefully we'll get down to the bottom of this issue and get it fixed for RC2.

Cheers,
-Sumit Chandel

[Axel Kittenberger]

my (pretty huge) project, my computer:

26 seconds to compile in 1.4.61

vs.

37 seconds to compile in 1.5.0 RC1

So here it is 70% slower.

--
1.5.0 RC1 uses more RAM too, java default settings worked fine for me
with 1.4.61 but I needed to increase heap for 1.5.0 RC1

[Dev]

Can You explain how to change this settings in Eclipse?