I fully agree with Russel. I'm not really worried about Gradle's performance at the moment. I mainly wanted to provide some feedback because these results came as a surprise to me.
Cheers, Peter Russel Winder-4 wrote: > > On Sun, 2009-05-31 at 13:14 -0700, Curtis Cooley wrote: >> On Sun, May 31, 2009 at 12:21 PM, Peter Niederwieser <[email protected]> >> wrote: >> > I have a HelloSpock project that contains a single Groovy class (a >> Spock >> > specification). What puzzles me a bit is that 'gradle test' takes 10 >> seconds >> > to complete. By comparison, 'ant test' takes 3 seconds, and 'mvn test' >> 8 >> > seconds. This is on repeated invocation, i.e. all downloading and >> > compilation has already taken place. Do you consider this acceptable? >> Would >> > the difference be less pronounced for bigger projects? >> >> I think what you are seeing is the startup cost of Gradle, which in my >> observations is higher than Ant's. When you get to 60 second >> build/test runs then you should be seeing 53 second ant builds and 60 >> second Gradle builds. Whether that is acceptable is up to you. > > The problem is that those of use with smaller builds are a bit concerned > with the fact that Gradle is slower than Maven and definitely slower > than Ant. > > No matter whether justified or not, whether it can be ameliorated or > not, small builds is where people make comparison judgements, and where > benchmarks are created. There is also a tendency for detractors of a > technology to obsess about performance issues -- witness the arguments > about Groovy itself, and indeed the hassles SCons is getting. > > I think there are more important technical evolutions lined up for 0.7, > and I think they should remain the priority. However, I think > performance should be reviewed for 0.8. There was a review previously > and this led to a major rewrite of large tracts of Gradle source from > Groovy to Java, and this successfully slashed run times. > > Perhaps a new stage of profiling on a number of projects is in order to > find the "hot spot" and see if there are factors stopping the JIT from > doing its job. Or perhaps the problem is a class written in Groovy that > needs to be rewritten in Java. Alternatively there are just > infelicities in the Java that have not been picked up. > > Gradle's performance is in the right scale so I don't think there is a > crisis here, so I don't think there needs to be any deep worrying. > However it would be good to get performance closer to Ant and definitely > better than Maven. > > To progress this we need to set up an experiment where as many people as > possible execute their build with profiling so as to provide data. I > can't volunteer to drive this, but if there is anyone out there with > strong profiling experience who can, that would be fantastic. > -- > Russel. > ============================================================================= > Dr Russel Winder Partner > xmpp: [email protected] > Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 > 41 Buckmaster Road, f: +44 8700 516 084 voip: > sip:[email protected] > London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder > > > -- View this message in context: http://www.nabble.com/Gradle-performance-tp23806096p23817754.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
