Tom Eyckmans wrote:
2009/9/9 Hans Dockter <[email protected] <mailto:[email protected]>>
On Sep 9, 2009, at 8:27 AM, Hans Dockter wrote:
On Sep 9, 2009, at 1:25 AM, Adam Murdoch wrote:
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.
This doesn't seem right to me if you store the state of a directory
that is used by multiple projects you will have always have one
project not acting on new/changed/deleted files, so this should really
be in the project .gradle directory.
Then you'd have exactly the same problem if that project is included in
multiple builds.
What I meant was that I'd like us to store all our state under ~/.gradle
somewhere. It would be separated by build or project as appropriate
under that directory.
Some benefits of storing this stuff under $userHomeDir:
- We deal with read-only source trees.
- All the state for a build is under one directory heirarchy. This makes
it easy to garbage collect. Right now we store some stuff in
$userHomeDir, some in $rootDir/.gradle, some in $projectDir/build.
- We have a command-line option to specify $userHomeDir, so that a user
or a CI build can point this to whichever location they prefer. Which
might be $rootDir/.gradle. They can also do the same in an init script.
- We don't litter .gradle dirs through the source tree. I find this
quite annoying, and I don't imagine I'm alone.
Actually, these are really the benefits of having a single state
directory heirarchy per build. It could be $userHomeDir, or it could be
$rootDir/.gradle
Adam
