Turns out this change also has a nice effect on test execution. It varies from around 11% faster than 1.6 for the junit and testng performance test projects up to almost 50% for the verbose testng test project.
Anything that uses the worker process should pick up this improvement, which includes Groovy and Scala compilation. We don't have a performance test for this and I haven't measured this. Might be worth doing so. The change also add 2-5% to the IDE import tasks. With the dependency meta-data caching, the numbers for 1.7 are looking pretty good: - Our canonical multi project build is about 5% faster than 1.6 for both clean and incremental build (20% faster than 1.0). - The 'many dependencies' build is about 22% faster than 1.6 for both clean and incremental build (35% faster than 1.0). - Eclipse import is about 25% faster than 1.6 for the multi project build and 35% faster for the many dependencies build (slightly less relative to 1.0). - IDEA import is about 38% faster than 1.6 for the multi project build and 52% faster for the many dependencies build (slightly less relative to 1.0). - JUnit and TestNG execution is about 12% faster than 1.6 (18% and 14% faster than 1.0). - Verbose JUnit and TestNG execution is about 38% and 50% faster than 1.6 (39% and 43% faster than 1.0). - The dependency report for the many dependencies build is 63% faster than 1.6 (51% faster than 1.0). - Build script compilation is 77% faster than 1.6 (42% faster than 1.0). On 17/05/2013, at 6:07 PM, 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. > 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
