views:

7531

answers:

6

We're starting to make heavier use of GWT in our projects, and the performance of the GWT compiler is becoming increasingly annoying.

We're going to start altering our working practices to mitigate the problem, including a greater emphasis on the hosted-mode browser, which defers the need to run the GWT compiler until a later time, but that brings its own risks, particularly that of not catching issues with real browsers until much later than we'd like.

Ideally, we'd like to make the GWT compiler itself quicker - a minute to compile a fairly small application is taking the piss. However, we are using the compile if a fairly naive fashion, so I'm hoping we can make some quick and easy gains.

We're currently invoking com.google.gwt.dev.Compiler as a java application from ant Ant target, with 256m max heap and lots of stack space. The compiler is launched by Ant using fork=true and the latest Java 6 JRE, to try and take advantage of Java6's improved performance. We pass our main controller class to the compiler along with the application classpath, and off it goes.

What else can we do to get some extra speed? Can we give it more information so it spends less time doing discovery of what to do?

I know we can tell it to only compile for one browser, but we need to do multi-browser testing, so that's not really practical.

All suggestions welcome at this point.

+16  A: 

Let's start with the uncomfortable truth: GWT compiler performance is really lousy. You can use some hacks here and there, but you're not going to get significantly better performance.

A nice performance hack you can do is to compile for only a specific browser, by inserting the following line in your gwt.xml:

<define-property name="user.agent" values="ie6,gecko,gecko1_8">

This, for example, will compile your application for IE and FF only. If you know you are using only a specific browser for testing, you can use this little hack.

Another option: if you are using several locales, and again using only one for testing, you can comment them all out so that GWT will use the default locale, this shaves off some additional overhead from compile time.

Finally, there is a nice blog post on increasing compile-time performance:

Bottom line: you're not going to get order-of-magnitude increase in compiler performance, but taking several relaxations, you can shave off a few minutes here and there.

Yuval A
It appears for GWT 2.0, you actually want this syntax to specify a user agent: <set-property name="user.agent" value="gecko,gecko1_8" />
mooreds
+3  A: 

The GWT compiler is doing a lot of code analysis so it is going to be difficult to speed it up. This session from Google IO 2008 will give you a good idea of what GWT is doing and why it does take so long.

My recommendation is for development use Hosted Mode as much as possible and then only compile when you want to do your testing. This does sound like the solution you've come to already, but basically that's why Hosted Mode is there (well, that and debugging).

You can speed up the GWT compile but only compiling for some browsers, rather than 5 kinds which GWT does by default. If you want to use Hosted Mode make sure you compile for at least two browsers; if you compile for a single browser then the browser detection code is optimised away and then Hosted Mode doesn't work any more.

An easy way to configure compiling for fewer browsers is to create a second module which inherits from your main module:

<module rename-to="myproject">
  <inherits name="com.mycompany.MyProject"/>
  <!-- Compile for IE and Chrome -->
  <!-- If you compile for only one browser, the browser detection javascript is optimised away and then Hosted Mode doesn't work -->
  <set-property name="user.agent" value="ie6,safari"/>
</module>

If the rename-to attribute is set the same then the output files will be same as if you did a full compile

Dave Webb
+4  A: 
  • Split your application into multiple modules or entry points and re-compile then only when needed.
  • Analyse your application using the trunk version - which provides the Story of your compile. This may or may not be relevant to the 1.6 compiler but it can indicate what's going on.
Robert Munteanu
That SOYC stuff looks neat, thanks for the tip.
skaffman
+9  A: 

If you run the GWT compiler with the -localWorkers flag, the compiler will compile multiple permutations in parallel. This lets you use all the cores of a multi-core machine, for example -localWorkers 2 will tell the compiler to do compile two permutations in parallel. You won't get order of magnitudes differences (not everything in the compiler is parallelizable) but it is still a noticable speedup if you are compiling multiple permutations.

If you're willing to use the trunk version of GWT, you'll be able to use hosted mode for any browser (out of process hosted mode), which alleviates most of the current issues with hosted mode. That seems to be where the GWT is going - always develop with hosted mode, since compiles aren't likely to get magnitudes faster.

Chi
Ah, the localWorkers option is a gem, that's worth knowing. Sadly, most of our dev boxes are single-core xeons. That OOPHM looks very promising, too. Always in the next version, it is...
skaffman
virtualize a compiling enviroment on a box with multiple cores; remote into this vm; execute command line GWT compile using -localWorkers, with minimal locals and user.agents; make sure the box hosting the vm is a network peer to where you are deploying to. The combination of this gets your compile down to about 30 seconds w/ deployment in tomcat. In addition all of this can be written in a script. You can also dev on a local machine, create a svn patch, and have your script apply the patch using some type of NFS or samba sharing, eliminating the need to copy over just the src diffs. yay!
kr
NX client is also a huge +++ for remote dev on limited ADSL, Cable, or WiFi connections. Plus you always are in sync no matter what comp you are using at any location w/ internet
kr
+3  A: 

There was a talk on this very subject at Google I/O. Check it out here

Carnell
+4  A: 

Although this entry is quite old and most of you probably already know, I think it's worth mention that GWT 2.x includes a new compile flag which speeds up compiles by skipping optimizations. You definitely shouldn't deploy JavaScript compiled that way, but it can be a time saver during non-production continuous builds.

Just include the flag: -draftCompile to your GWT compiler line.

monzonj