The symptom is much slower script compilation in Gradle 1.6 relative to previous versions, so it particularly affects those people using a particular build for the first time or those who are authoring build scripts.
The cause was 2 things in combination: a much larger number of packages in the default imports, now that we generate it, and some inefficiencies in how we find classes in the class loader graph, in particular when looking for classes that don't exist. These two things meant that the Groovy compiler was spending a lot of time resolving unqualified class names when compiling scripts. The solution is a bit of caching in key places in the class loader graph. Some numbers: For a build with 100 projects, average execution time for `gradle help --recompile-scripts` is Gradle 1.5 ~48sec Gradle 1.6 ~96sec Master ~24sec The fix also knocks about about 30-40 minutes off the CI commit builds. Nice. Yet to see what impact it has on the coverage builds. The daemon is also slightly faster for each build now, thanks to the caching. On 14/05/2013, at 9:20 PM, Luke Daley <luke.da...@gradleware.com> wrote: > I think we have a problem. > > I've been seeing something like this too I think. > > What can we ask for short of access to the project? How can we see where the > time is being spent? > > Begin forwarded message: > >> From: Gradle <noreply.gra...@getsatisfaction.com> >> Subject: New problem: Performance degradation in initial Gradle invocation >> when usin... >> Date: 14 May 2013 12:15:18 PM GMT+01:00 >> To: luke.da...@gradleware.com >> >> Stefan Marklund just reported this problem in Gradle: >> >> Performance degradation in initial Gradle invocation when using 1.6 >> >> Hello All, >> >> After the other day having switched over to Gradle 1.6 from Gradle 1.5 I >> have noticed a significant performance decrease in the initial configuration >> step in Gradle 1.6 compared to the 1.5 version. With initial invocation of >> gradle I mean after having done a clean code checkout invoking Gradle for >> the very first time. >> >> See numbers below. Are you aware of any performance issue associated with >> the 1.6 version? >> >> I have not adjusted my build script for changes pending (for Gradle 2.0) so >> I do see some new deprication messages. >> >> My Gradle project is fairly large I'd imagine. It is a multiproject >> containing 198 subprojects. >> >> Performance numbers for an initial 'gradle tasks' >> >> >> Gradle 1.6: >> =========== >> Total time: 5 mins 25.951 secs >> Total time: 5 mins 47.84 secs >> Total time: 5 mins 32.74 secs >> Total time: 5 mins 7.843 secs (no daemon) >> Total time: 5 mins 31.888 secs (no daemon, profile) >> >> Profile: >> Description Duration >> Total Build Time 5m31.91s >> Startup 1.094s >> Settings and BuildSrc 3.249s >> Loading Projects 0.561s >> Configuring Projects 5m0.02s >> Task Execution 26.779s >> >> Dependency resolution 1.125s >> >> Gradle 1.5: >> =========== >> Total time: 2 mins 31.647 secs >> Total time: 2 mins 25.89 secs >> Total time: 2 mins 21.674 secs (no demon) >> Total time: 2 mins 28.045 secs >> Total time: 2 mins 48.135 secs (no-daemon, profile) >> >> Profile: >> Description Duration >> Total Build Time 2m48.16s >> Startup 1.060s >> Settings and BuildSrc 2.417s >> Loading Projects 0.573s >> Configuring Projects 2m17.26s >> Task Execution 26.138s >> >> Dependency resolution 1.164s >> >> >> >> Across the board the configuration time per subproject is about twice that >> of Gradle 1.5. The other items are virtually identical. >> I also supplied the dependency resolution times. >> >> Subsequent invocations of 'gradle tasks' are done in ~35s for both Gradle >> 1.5 and 1.6. >> >> I hope this aids you in your analysis. >> >> Thank you, >> Stefan Marklund >> Reply | Notify me when people reply >> >> This message sent from the Gradle community on Get Satisfaction. >> To unsubscribe or change your email settings, click here. >> >> >> ---------------- >> Create a customer community for your company at GetSatisfaction.com. >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
