We have dozens of GWT modules here at GT Nexus. To many, that statement will raise red flags and perhaps accusations of questionable architecture, but the fact is that we have a very large product suite and implementing products in their own modules is working very well for us.
The downside of this design is that compiling all our GWT modules takes a very, very long time, even on modern silicon (and germanium, etc.).
The Google Web Toolkit team is aware of how long compiles take, however their emphasis is on enhancing the user experience; if that comes at the expense of a longer compile for developers, that’s OK with them. For instance, they claim that “an extra 30 seconds of compiler time is worth it to get a 5% improvement in code size.” I appreciate that perspective, but I also want faster compiles!
To start, there are two things that you can do with a modern multi-core machine to speed up your compiles; I do not have these in my notes from Google IO 2010, but they are well-advertised in the GWT community. Namely:
- If you are using Ant, use the <parallel> tag to compile modules in parallel. This can yield phenominal results.
- Use the GWT -localWorkers argument to use multiple threads during compilation.
In addition, the GWT team recommends:
- Use two module definitions for each module; for instance, “MyProject.gwt.xml” and “MyProjectDev.gwt.xml,” and tune the “Dev” version to compile with Pretty formatting, for one browser (if possible), and other common methods for speeding up the compiler
- Use the -draftCompile compiler flag to avoid complicated optimizations (for development)
- Use pretty output for development
Their non-compiler-related suggestions are:
- Use better hardware.
- Use RAID/SSD
- Use -server JVM flag and more memory
In addition, there are capabilities in the GWT compiler that have not yet been exposed or well documented. For instance, there is support for parallelized and clustered builds by using the precompiler and certain “CompilePerms.” See the Google IO 2010 presentation linked to below for more information on this option.
Beyond that, the old standby is to identify the modules that you are not interested in compiling and comment them out. That is perhaps the most effective tool we currently have in our environment to speed up our compiles, short of not compiling the GWT modules at all.
The GWT compiler often works some wonderful magic, but that magic comes at the price of slow compile times. We have had varying success with these techniques, but the GWT team appears to be aware of them and will hopefully toss us a bone in the future to help developers become even more productive with their toolkit.
- “Making Faster Apps Faster” presentation at Google IO 2010
- Using Ant parallel and multiple local threads on lifeandcode.net
- Lombardi’s take on parallel and local threads
- Ben Northrup’s Article on Structuring GWT Applications (Added 2/2011)