GWT compile times with GWT 1.6

April 23rd, 2009 Alex Moffat Posted in EffectiveGWT, GWT | 3 Comments »

GWT generates browser and locale specific JavaScript when it compiles your Java code. Each combination of browser and supported locale, referred to as a permutation, potentially gets a separate JavaScript file if needed. With just the default locale you’ll end up with five permutations, for the five values of the user.agent property GWT supports. If you add a second locale you end up with ten permutations. Before the release of 1.6 GWT these were compiled one after the other. GWT 1.6 can now compile multiple permutations in parallel. I’ve done a little experimenting to see what effect this has on compile times for Blueprint.

The compile process for Blueprint already compiles multiple pages in parallel using the ant parallel task so it’s interesting to see how this interacts with parallel compilation of multiple permutations for a single page. The number of parallel permutation compilations depends on the value of the -localWorkers flag passed to the compiler. This has a default value of 1 and the higher the number the more permutations get compiled at once. There is an initial serial portion of the compile process during which the permutations are computed and then you’ll see the parallelization kick in.

As a baseline the GWT compile portion for building Blueprint takes 2 minutes 26 seconds on my desktop machine using GWT 1.5.3. This is running a maximum of four page compilations in parallel while compiling seven pages and uses 100% of all four cores I have available.

The same configuration with GWT 1.6.4, that is -localWorkers not set or set to 1 and with the ant parallel task set to allow 4 parallel compiles, takes an average of 2 minutes 11 seconds. A nice saving of 25 seconds for the compile time without having to do anything. If I hold the number of parallel page compilations constant at 4 and increase the -localWorkers value the execution time slowly increases, to 2 minutes 12 seconds for 2 workers, 2 minutes 14 seconds for 3 workers and 2 minutes 25 seconds for 4 workers (back to the 1.5.3 time). This is what you’d expect, compilation is limited by the cpu power available so the goal is to always run as many compilation processes as you have free cores and no more. Using the ant parallel task does this for Blueprint because there are more pages than cores and with seven pages the difference in page sizes means there are almost always four compiles running in parallel.

The Blueprint build process also supports building a single page, which is useful if you need to test just one page in multiple browsers. Here the -localWorkers flag is very useful. With 1 local worker the compile time for our largest page is 112 seconds, and this steadily drops as you increase the number of workers, with 2 it’s 83 seconds, with 3 it’s 72 seconds, with 4 it’s 70 seconds and finally for 5 it’s 63 seconds. I drew the pictures below to help me visualize what’s going on.

I’m going to go with -localWorkers 1 when compiling the whole application and -localWorkers 5 when compiling a single page.

Rather like overclocking cpus there is the potential for wasting more time than it’s worth to try to get the absolute fastest possible compile. For instance, what’s the optimum ordering of Blueprint pages for parallel compilation?