On 17/05/2013, at 6:10 PM, Luke Daley <luke.da...@gradle.biz> wrote:
> > > On 17/05/2013, at 9:07, Adam Murdoch <adam.murd...@gradleware.com> wrote: > >> >> 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. > > Are you serious? 30 - 40 mins?!? The Linux build has gone from around 70 minutes to around 40 minutes. The Windows build has gone from around 100 minutes to around 65 minutes. This will be the caching, rather than the script compilation, as these builds are using in-process int tests. It looks like the daemon builds are also faster after this change, perhaps 10-20 minutes. The coverage builds haven't really changed, which makes sense as there's no real opportunity to make use of the caching and the tests builds usually have a very small number of build files. The parallel build is also 90 minutes faster, too, but that's not related to the caching. I changed this build to use max forks of 2 (up from 1). > >> 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 >> -- 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
