On 19/05/2013, at 10:45 PM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > 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). Great stuff. I guess there's not much we can do to avoid this (the 1.6 degradation) happening in the future that we aren't doing already. Maybe just points out the value in investing in the performance test suite and means we should give it more attention. > 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 > -- 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 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
