2009/9/18 Adam Murdoch <a...@rubygrapefruit.net> > > > Tom Eyckmans wrote: > > > > 2009/9/9 Hans Dockter <m...@dockter.biz> > >> >> 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. > True
> > 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 > > Totally agree > > Adam > >
