Compile time is much longer after upgrading to newer version of SmartGWT

We were using 5.0p from 12-10-2015. We tried upgrading to 6.0d 3-1-2016. That is all that changed and our compile time went up significantly. What's up with that? Here the output from our compiles:

5.0p:

     [java] Compiling module com.hp.cp.pm.gwt.linker.PMLinkerDev
     [java]    Compiling 3 permutations
     [java]       Compiling permutation 0...
     [java]       Process output
     [java]          Compiling
     [java]             Compiling permutation 1...
     [java]       Compiling permutation 2...
     [java]    Compile of permutations succeeded
     [java]    Compilation succeeded -- 68.795s
     [java] Linking into D:\SVN\PC\2.0.1\prod_manager\.\build\gwtc\com.hp.cp.pm.gwt.linker.PMLinker
     [java]    Link succeeded
     [java]    Linking succeeded -- 9.858s

6.0d:

     [java] Compiling module com.hp.cp.pm.gwt.linker.PMLinkerDev
     [java]    [WARN] Warnings in 'jar:file:/D:/SVN/PC/trunk/prod_manager/lib/smartgwt.jar!/com/smartgwt/client/widgets/calendar/Calendar.java'
     [java]       [WARN] Line 5055: Referencing deprecated class 'com.smartgwt.client.widgets.calendar.events.CalendarEventMoved'
     [java]       [WARN] Line 5327: Referencing deprecated class 'com.smartgwt.client.widgets.calendar.events.CalendarEventResized'
     [java]       [WARN] Line 6040: Referencing deprecated class 'com.smartgwt.client.widgets.calendar.events.EventHoverHTMLEvent'
     [java]       [WARN] Line 7463: Referencing deprecated class 'com.smartgwt.client.widgets.calendar.events.TimelineEventMoved'
     [java]       [WARN] Line 7518: Referencing deprecated class 'com.smartgwt.client.widgets.calendar.events.TimelineEventResized'
     [java]    Compiling 3 permutations
     [java]       Compiling permutation 0...
     [java]       Process output
     [java]          Compiling
     [java]             Compiling permutation 1...
     [java]       Compiling permutation 2...
     [java]    Compile of permutations succeeded
     [java]    Compilation succeeded -- 381.148s
     [java] Linking into D:\SVN\PC\trunk\prod_manager\.\build\gwtc\com.hp.cp.pm.gwt.linker.PMLinker
     [java]    Link succeeded
     [java]    Linking succeeded -- 6.490s

Note that the compile time went from 68 seconds to 381 seconds (5.6 time slower).

[Isomorphic]

We're definitely not seeing giant increases in compile time, and there's been no dramatic increase in API size or complexity that could explain such an increase.

We'd suggest looking closely at other ways in which the two environments you're testing are different. Maybe they are on a slower disk, or this is a one-time increase from copying files from the .jars, or you updated Eclipse or core GWT at the same time - something like that.

The only thing that is different is the smartgwt jar. These are command-line compiles on the same system. If I switch the jars back the times go back to the way they were. In Eclipse the compile time is even worse (tried with both Dev mode and SuperDev mode). Both are far worse with the newer jars. All we did is replace the two jar files.

It's looking like it has something to do with the gwt compiler unit cache. If there's no cache or the cache is from a different version it appears that the first compile takes a long time. After the cache is build, subsequent compiles are much quicker. Still trying to verify that that is what is happening.

[Isomorphic]

Right, a slower first-ever compile is what we had guessed - the first ever compile both populates that cache and potentially copies skin files and other static resources.

Let us know if it turns out to be anything more than this.

This appears to be what it was. Gwt is creating three directories in my output dir (gwtc, gwtc-temp and gwtc-unitCache). I cleaned my output directory, and then compiled several times. The times per attempt looked like 238s, 238s, 57s, 54s, 50s, and 55s. I then repeated this and the times were 224s, 259s, 56s, 54s, 56s. Not certain why it is slow the first two times not just the first time. That is what confused me because I expected it the first time, but when it continued to happen on the second compile I thought it must have been something else.

[Isomorphic]

That's very strange that it only gets faster the third time. Perhaps it's a bug in Eclipse where there is a once-ever failure to use the cached resources.

In any case, it's good you posted it, as someone else might have the same experience and likewise assume the compile time had permanently become slower.

This was not using Eclipse, it was a command line compile.

[Isomorphic]

Wow, that's even stranger, as that means there's no state that can be maintained from run to run, other than filesystem state.

If you have the time and inclination, you might check out what's going on in terms of file IO by using "strace" or any similar tool.