Last time when we talked about build systems, we looked at some tips that might make your Maven build faster. The results we got were fascinating and the response was overwhelming. Most people were pretty happy with the speedup that they achieved on their projects from the tips we gave. Today, we’re going to look at what can be done with Gradle builds. The builds of most projects are quite standard, but yet they are unique. Almost all projects add their own complexity into the build. And while they are all different, one thing is common: builds can take up your precious time and speeding it up can affect the developer productivity which makes working on your project more pleasant. 
Without further ado, let’s see what Gradle, with its “Realize Build Happiness” motto, is packing in its speed department. 


This blogpost is largely inspired by the wonderful session by <a href="<a href="" rel="nofollow">Madis" rel="nofollow">">Madis Pink: <a href="<a href="" rel="nofollow">Squeezing" rel="nofollow">">Squeezing the Last Drop of Performance Out of Your Gradle Builds. 


Before we start any optimizations, we need to first understand that a Gradle build has a lifecycle, which can be split into three distinct phases:
* Initialization - scanning the projects to find out which ones to build.

* Configuration - running the build.gradle scripts and building the task graph.

* Execution -  the useful part where Gradle actually builds your app.

Now you can see the pain right away. There’s clearly one useful phase that we might be able to speed up in our own build scripts if the peculiarities of a particular project allow it, and two phases in which Gradle exclusively performs selfish tasks: configuring itself and imposing the execution overhead. In this post we’ll first concentrate on reducing the overhead of the build before we try to make the build itself faster.


Continue reading the full article on RebelLabs: