Hi,
I've made some changes to the assembly of classloaders for running
isolated Ant tasks. This is used by the GroovyCompile and GroovyDoc
tasks. In particular, we now cache the ClassLoader for a given
ant+groovy combination. This results in some nice performance
improvements for Groovy projects.
For the Groovy quickstart sample:
using 0.7: gradle clean jar takes 9.9 seconds
using head: gradle clean build takes 8.1 seconds
Using the Groovy multi-project performance test build (25 projects):
using 0.7: gradle clean jar takes 2 min 39 seconds
using head: gradle clean build takes 1 min 35 seconds
Note that these builds do not fork the compiler or test execution. I
doubt we will see any improvement when forking (I haven't measured it)
Adam Murdoch wrote:
Hi,
I've just committed fixes for some performance regressions which have
snuck in since the 0.7 release:
- Ported AnnotationProcessingTaskFactory from Groovy to Java, and
added some caching.
- Use ASM instead of Groovy to generate task subclasses which mix in
convention mapping and dynamic properties.
- Cache all scripts. In particular, cache empty/missing init scripts
and the default buildSrc script. More on this below.
Using our performance test multi-project build (which has 25
projects), gradle -t executes in:
Gradle 0.8-20090829161512+1000: 8.41 seconds (this is the version
we're using for gradlew)
Gradle 0.7: 3.98 seconds
Gradle head: 3.58 seconds
So, head is a now a little faster than the 0.7 release.
Also, the developerBuild is down from ~30 min to ~20 min on my
not-particularly-good laptop.
One implication of caching every script is that we don't always have a
directory in which to put the .gradle cache. So, I've changed the
script compilation to cache all scripts under ~/.gradle/scriptCache.
An advantage of this is we no longer end up with .gradle directories
scattered all through the source tree (unless you end up using an
internal repository). The downside is we will need some way to garbage
collect this cache. This isn't actually a new problem, because we
needed to solve this any way - It's just more important now.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
