How to Reduce Compilation Time for Your GXT Projects

GWT developers are always looking for ways to speed up the development cycle. Colin Alworth has previously written an excellent blog post on GWT compiler options that can be used to select for faster builds or smaller output for GXT apps. In this post, I want to highlight the two most useful options for speeding up GWT development and show how to select them using a maven profile. Used together, these techniques can reduce compilation time for GXT projects by more than 50%.

Speed up Super Dev Mode (SDM) Launch

GWT super dev mode, which is now well integrated in IntelliJ Ultimate Edition and (soon) Google Plugin for Eclipse, does incremental compilation to bring page refresh time down to a few seconds for most applications. However, the initial compilation can still take a minute or more depending on the size of your app. Typically, about half the time is spent creating any required permutations. In GWT 2.7, the browser request that triggers initial compilation in super dev mode will include enough information (such as user agent and language) to select a single permutation; however, if your application includes properties that generate additional permutations, you can use a tag in your gwt.xml to collapse them all into a single permutation. Simply include this in your gwt.xml:

If you’re currently seeing SDM build multiple permutations, this will likely cut your initial SDM launch time by half. Note, however, that this technique may not work well in older versions of GWT (before 2.7) and may actually require more time to do the initial compile if SDM is already building only one permutation. With GWT 2.7 and later, you should only need to use it with SDM if your application defines additional properties which result in building multiple permutations at SDM launch time.

Speed Up Full Compilation

The <collapse-all-properties /> switch is always useful when doing a full compilation because in this case, the compiler must otherwise build all the permutations. Keep in mind that the resulting output is 15-20% larger than any single permutation would be so this is not recommended for your final production build. However, for a quick development build, it’s very useful.

In addition, when you are doing a development build, you can use the -draftCompile option to get about a 25% reduction in compile time at the expense of less optimized output. For functional testing or debugging, this is a great tradeoff. Obviously, it should not be used for any performance-related testing, however.

The combination of <collapse-all-properties /> and -draftCompile will normally result in a 60-70% reduction in compile time.

Setting gwt.xml Properties for Development Only

When you are using <collapse-all-properties /> or other techniques such as setting a single user agent in gwt.xml, you don’t want to accidentally leave these options in place when compiling for production. A simple way to avoid this is to create an additional gwt.xml which inherits all properties from the base gwt.xml. Both gwt.xml files should use the rename-to attribute with the same module name. The development-only version should inherit everything from the base module and set or override properties which apply to development only. Here is a simple example from my contactmgr example project:

contactmgr.gwt.xml:

    
    
    
    
    
    
    
    
    
    
    ...
    
    

contactmgr-dev.gwt.xml:

In your IDE, you can then create a run configuration specifically for the -dev.gwt.xml. Using this simple technique, you can continue to manage all your module dependencies and properties in the main gwt.xml while setting development-only properties such as logging switches and <collapse-all-properties /> in a separate file.

In the next section, we’ll look at how to select development options using a maven profile.

Setting Development Options in a Maven Project

In a maven project using gwt-maven-plugin, we can build on this technique to set compiler options using a maven profile. In my projects, I set the default gwt-maven-plugin configuration to use -draftCompile and the -dev.gwt.xml. I use a separate release profile to do the slower production build with all permutations, optimization, obfuscation, etc. Here’s a snippet from the contactmgr sample pom.xml showing the technique:

    
        
            org.codehaus.mojo
            gwt-maven-plugin
            ${gwt.version}
            
                INFO
                
                -Xmx1g -Xms64M
                
                true
                

  com.example.contactmgr.contactmgr-dev
                    
                    com.googlecode.mgwt.ui.Animation
                    com.turbomanage.gwt.Util
                
            
        
    

    
        release
        
            
                
                    org.codehaus.mojo
                    gwt-maven-plugin
                    ${gwt.version}
                    
                        INFO
                        
                        true
                        -Xmx1g -Xms64M
                        
com.example.contactmgr.contactmgr
                        
                    
                    
                        
                            gwtcompile
                            prepare-package
                            
                                compile
                            
                        
                    
                
            
        
        
            OBFUSCATED
        
    

Note that the default configuration of gwt-maven-plugin specifies the development-only GWT module (contactmgr-dev) while the release profile specifies the base version. To do a full production build, use mvn -Prelease; otherwise, maven will use -draftCompile and the -dev.gwt.xml to reduce compile time.

If your project is particularly large and you use a continuous integration server like TeamCity or Jenkins, you may want to consider using -draftCompile and <collapse-all-properties /> in your builds for pull requests (commits) so you can get build status quicker. For example, using -draftCompile and <collapse-all-properties />, the GXT Explorer project builds in about 6 minutes vs. 18 minutes. There’s likely no reason why you need to build fully optimized and obfuscated output every time someone submits a code change.

Using these techniques in your enterprise GXT development projects should help your team to be more productive. Let us know how it goes. You can submit questions to the GXT forum.