On 14/11/2012, at 10:58 AM, Hans Dockter wrote: > > > On Tuesday, November 13, 2012, Adam Murdoch wrote: > > On 14/11/2012, at 1:37 AM, Luke Daley wrote: > >> >> On 13/11/2012, at 2:10 PM, Peter Niederwieser wrote: >> >>> Now that 1.3 is almost out, I'd like to discuss potential next steps for >>> improving our Scala support. Here is an initial list: >>> >>> * Scala REPL support >>> To make this work well, we need to solve the general problem of Java code >>> reading from and writing to the console when running in Gradle (with and >>> without Gradle Daemon). Currently, there are issues with the Gradle status >>> line getting in the way, and control characters not being interpreted >>> correctly. The latter is important for accessing the shell's history. >>> >>> * Reusing the Scala compiler across builds >>> We already reuse the compiler across ScalaCompile tasks in the same >>> build, which led to big performance improvements. Reusing the compiler >>> across builds (as done by sbt and Zinc/Nailgun) will provide further gains. >>> In other words, we need to enhance the compiler daemon so that it can >>> outlive a build. Question is if we add this capability specifically for the >>> compiler daemon, or work towards a unified solution (for all daemons, or for >>> all daemons except the Gradle Daemon). >> >> Without knowing the technical details, it seems crazy to me to do a Scala >> specific solution here. > > The question is more whether it's a compiler daemon specific solution or some > kind of common daemon solution. > > I would be interested in the performance gains it can bring to Groovy and > Java projects.
We can measure this now: Enable the (build) daemon. Switch compiler forking on, run a few builds. Switch compiler forking off, run a few builds, and add about 15-20ms per compile for the cost of talking between processes. We should do this before we decide to implement a persistent compiler daemon. If the numbers look good, we'd spike an implementation and measure again. > > Hans > > > My answer would be first a specific solution, moving incrementally towards a > common solution. > > For example, we might start by reusing the discovery mechanisms, where we use > the daemon registry infrastructure to find long running compiler daemon > instances. Then we might share more of the messaging infrastructure, so that > the build daemon (what we call 'the daemon') uses ObjectConnection to do > messaging. Then we might generalise the protocol, merging WorkerProcess and > DaemonClient so that the same (internal) API is used to kick off builds or > compilation or any other pieces of work. Then we might merge the single use > daemon and the worker process. And so on. > > Or we might come at it the other way, adding support for compilation to > DaemonClient, so that we use the long-running daemon or the single use daemon > for compilation, later generalising things and merging the daemon, the > compiler daemon and the worker process infrastructure. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
