I like those numbers a lot!
On Sun, May 19, 2013 at 11: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). > > > 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<http://forums.gradle.org/people/stefan_marklund?utm_content=profile_link&utm_medium=email&utm_source=new_topic>just > reported this problem in > Gradle<http://forums.gradle.org/gradle?utm_content=company_link&utm_medium=email&utm_source=new_topic>: > > > *Performance degradation in initial Gradle invocation when using > 1.6<http://forums.gradle.org/gradle/topics/performance_degradation_in_initial_gradle_invocation_when_using_1_6?utm_content=topic_link&utm_medium=email&utm_source=new_topic> > * > 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<http://forums.gradle.org/gradle/topics/performance_degradation_in_initial_gradle_invocation_when_using_1_6?do=reply&utm_content=reply_link&utm_medium=email&utm_source=new_topic>| > Notify > me when people > reply<http://forums.gradle.org/gradle/topics/performance_degradation_in_initial_gradle_invocation_when_using_1_6/follow?utm_content=follow_link&utm_medium=email&utm_source=new_topic> > ------------------------------ > > This message sent from the Gradle community on Get Satisfaction. > To unsubscribe or change your email settings, click > here<http://forums.gradle.org/me/notifications?utm_medium=email&utm_source=new_topic>. > > > ---------------- > > Create a customer > community<http://forums.gradle.org/plans?utm_campaign=create_a_community&utm_content=create1&utm_medium=email&utm_source=notifications_email>for > your company at > GetSatisfaction.com <http://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 > > -- Szczepan Faber Principal engineer@gradleware; Lead@mockito Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
