Hans Dockter wrote:
On Sep 2, 2009, at 1:44 AM, 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.
There are other areas where we also need a place to store metadata. In
those cases we don't have the situation of possibly not having a
directory.
- Changedetection (at the moment stored in <checkedDir>/.gradle)
Should we move this also to ~/.gradle ?
I think we should cache everything in the same place. But that's really
just my personal preference.
- task history (build/.gradle/task-execution-history)
I thought it makes sense to put the task history in the build dir. If
the output is deleted you might as well delete the history (which
purpose is to control which output needs to be reproduced). We avoid
any GC/stale problems that way.
Except it's not quite right. It assumes all tasks which generate output
do so into the build directory. This means that after a clean, we'll
incorrectly re-execute tasks which generate their output somewhere else,
or which do not generate any output.
The rule for skipping a task is: skip the task if 1) its input files
have changed since last time it successfully executed, and 2) its output
files exist.
It's predicate 2) which deals with rebuilding after a clean, not
predicate 1). This means there's no reason to store this information in
the build directory.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
