Gradle Build Daemon

What?

The build daemon refers to an approach to improve the startup and execution time of Gradle.

Why?

For some workflows, the user invokes Gradle many times to execute a small number of relatively quick tasks. For example:

• When using test driven development, where the unit tests are executed many times.
• When developing a web application, where the application is assembled many times.
• When discovering what a build can do, where gradle -t is executed a number of times.

For these sorts of workflows, it is important that the startup cost of invoking Gradle is as small as possible.

In addition, user interfaces can provide some interesting features if the Gradle model can be built relatively quickly. For example:

• Content assistance in the IDE
• Live visualisation of the build in a GUI
• Tab completion in a CLI

Implementation

The basic idea is that the gradle command forks a daemon process, which performs the actual build. Subsequent invocations of the gradle command will reuse the daemon, avoiding the startup costs. Benchmarking based on a prototype yielded some excellent results.

An alternative approach is to implement a Gradle shell. The daemon approach is preferrable for a few reasons:

• The performance improvements are available from other Gradle UIs. The Gradle GUI and IDE plugins can take advantage of the daemon to speed up execution. Using the daemon even allows for a mixed model, where the user uses different UIs at different points in the workflow.
• We don't have to implement and maintain a shell. Implementing a shell, while probably a fun exercise, has very little to do with Gradle's core domain, and as such represents a waste of effort.
• The performance improvements are available in any shell the user happens to prefer, and are available in shell scripts.
• The daemon allows some interesting additional features to be implemented (see below)
• A daemon provides the first steps towards remote and distributed execution.

Some notes:

• Some details are available here: http://gradle.markmail.org/thread/xbqna6lowvsmm4ve
• An experimental version is included in the Gradle 0.9-rc-3 release.

Issues

• Concurrent builds
• Versioning
• Process cleanup
• Console and logging integration
• Ctrl-c detection
• Heap space and permgen space leaks
• File locking on windows
• GUI integration

Future work

• Preemptively build the model, so that it is ready when the user next invokes Gradle
• Preemptively check for and fetch snapshot dependencies
• Periodically garbage collect the Gradle caches
• Fast and accurate bash tab completion
• Use native file system change notifications (eg via jdk7 nio.2) to preemptively perform up-to-date analysis
• Generalise this system so that it can be used to make a pool of reusable processes available for compilation and testing. For example, both the Groovy and Scala compilers have a large startup cost. The build daemon could maintain a process with Groovy and/or Scala already loaded.

Gradle Build Daemon information lives in this chapter of the Gradle user guide.