On Saturday, December 21, 2013, Luke Daley wrote: <snip>
> > I'm pretty dubious about all of this. Looks to me like a difficult thing > to pull off outside of the compiler. I'm sure we can get something working, > but whether it's reliable enough and fast enough is another question > (hopefully answered by the spike). I also wonder whether investing into > more fine grained parallelism and coarser avoidance (e.g. ignoring non > visible classpath changes) wouldn't be more fruitful and more generally > applicable. > There are very different scenarios where this is helpful. - There are some large Gradle installations out there with massive single source trees with compile times of 2 minutes and more. - You have to see this also in the context of our upcoming continuous mode and deeper IDE integration where on the one hand Gradle compile is used with high frequency and on the other hand we don't have to scan the filesystem and we can keep the graph in memory. Last but not least it is long overdue that we need to have this graph available also for other important functionality: - Unused elements in the classpath - Enforcing API compatibility between modules - Incremental Testing - A lot of other interesting analytics tasks We have postponed this for years with the valid argument that just from a performance perspective there is bigger fish to fry. I think this statement is still valid. But considering the other extremely important functionality we can get out of this and that we will tackle for example fine grained parallelism in any case soon I think it is time to tackle this. In fact I would like to see at least some of the non performance related stories developed from the very beginning. Hans
