On 04/08/2011, at 1:03 PM, Magnus Rundberget wrote: > Apologies for sounding rather demanding/impatient in my previous posting. > I really believe in gradle and have come to really enjoy using it. I would go > as far as counting myself a gradle fan. Actively trying to convince people to > use it and recommending clients to adopt it. I'm obviously not a committer, > but hopefully i might be able to contribute little bits and pieces codewise > in the not to distant future. > > When I first evaluated gradle, build performance was a big issue for the > company I was consulting for. I still believe its very important for any > newcomers when first trying out gradle (gradle daemon and incremental builds > aside). This also applies for all those smaller projects where you expect > rapid turnarounds for your builds. > > Im guessing the performance issues here are related to the major rewrite of > the underlying cache solution, and its obviously understandable that there > will be issues with such an undertaking. > > I understand there are a lots of cool and important things which are in the > pipeline for gradle. I guess I just want to emphasize the performance aspect > and to raise a tiny flag of warning about the potential of "bad press" if a > release suddenly has a significant degredation.
We want to get better at this. We do actually have a performance test suite, and it did catch some regressions before we switched cache implementations, but it's clearly not complete enough. So, one of the things we'll do is grow this test suite to cover more cases. At the moment, the test suite is run manually, usually a bit before a release, so we might also set this up to run automatically. Regardless, we are currently working through the regressions, so the next release should be as performant as milestone-3, but much more correct wrt caching than milestone-3. > > Cheers > Magnus > > From: [email protected] > To: [email protected] > Date: Thu, 4 Aug 2011 01:56:36 +0000 > Subject: RE: [gradle-user] Why is gradle hitting remote repositories for > every build even after caching > > There was already a similar issue: http://issues.gradle.org/browse/GRADLE-1697 > Still hoping to hear a fix will be forthcoming, and that the next > rc/milestone will be back on par with m3 (or preferable faster). > > A little surprised that so few have complained about the rather dramatic > performance degredation. > > > Cheers > Magnus > > > From: [email protected] > > Date: Thu, 4 Aug 2011 09:37:04 +1000 > > To: [email protected] > > Subject: Re: [gradle-user] Why is gradle hitting remote repositories for > > every build even after caching > > > > > > On 04/08/2011, at 6:57 AM, Doug Lethin wrote: > > > > > Perhaps I'm just misunderstanding things, as I'm relatively new to Gradle > > > (rapidly becoming a big fan..), but I'm running into a curious problem > > > that I was hoping someone might be able to set me straight on. > > > > > > It seem to be related to milestone4, as I don't get the same behavior in > > > milestone-3. > > > > > > I have a build with *A LOT* of dependencies -- directly and transitively. > > > What I'm discovering is that each time I perform a build, for each > > > dependency, gradle is performing 3 requests: > > > > > > - HTTP HEAD for the pom file > > > - HTTP GET for the pom.sha1 checksum file > > > - HTTP GET for the pom.md5 checksum file. > > > > > > And occasionally it will redownload the jar files themselves, even though > > > nothing has changed. (These are not snapshot versions, but harcoded fixed > > > version numbers) > > > > > > It does this every time a build is performed. The the behavior I would > > > expect is that once a fixed version is downloaded from a repository, > > > there is no need to communicate to that repository in regards to that > > > resource. > > > > > > This is easily reproducible performing the 'gradle dependencies' command. > > > > > > For one of my projects in a multi-project build it it taking 1min49 > > > seconds just to list the dependencies using milestone-4 vs only 13 > > > seconds with milestone-3. > > > > > > Is this a bug in the new Wharf repository resolver, or am I missing > > > something obvious? > > > > It's definitely a bug. > > > > Can you please raise an issue so it gets addressed in the next release. > > > > -- > > Luke Daley > > Principal Engineer, Gradleware > > http://gradleware.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
