Decreasing build times by decreasing gradle memory requirements!

In this article we’ll explore ways to tweak the memory settings of our gradle build in order to squeeze some extra performance out of it and at the same time -in some cases- decrease the overall memory required instead of increasing it.

The android gradle plugin v2.1 brought dex-in-process to help developers decrease their build times. Dex-in-process allows you to use the same VM process that gradle uses to build your app to also do the dexing step of your build. In the past that would happen in multiple separate processes (by default 4), affecting thus performance. Running a “gradlew clean assembleDebug” build from the terminal takes around 2 minutes 30 seconds without dex-in-process, and 2 minutes with it for our project. Not bad eh?


In order to enable dex-in-process you only need to do one thing (apart from using the v2.1 of the android gradle plugin):

Make sure the dex process “fits” within the gradle process

What that means is that you need to make sure that the gradle process has enough memory allocated to it to be able to perform the whole dex step. Alright so how do we do that?

The gradle process memory settings can be found in the gradle.properties of your project. If they are not there (or are commented out) then the default value is used, which is 1 gigabyte.

My memory settings in my gradle.properties file. As you can see in this setup I am using 3 gb of memory for gradle

The dex process memory settings can be found in your build.gradle file. If they are not there, then the default value is used, which is 1 gigabyte.

My memory settings in my build.gradle file. As you can see in this setup I am using 4 gb of memory for dex

So the easiest way to do this is to increase the gradle memory setting enough to fit your dex step memory setting. If the dex process memory setting is the default (1 gigabyte) then you would need at least 2 gigabytes (hey, gradle needs some memory for it self as well right?). For my setup my dex step memory setting is 4 gigabytes as shown above, so I would need to increase my gradle memory setting to at least 5 gigabytes. You don’t even need to do any guess work for this as the build itself will display a warning on every build in the command line informing you how much you need to increase your gradle memory requirements by in order to enable dex-in-process!

Gradle warns you when dex-in-process has not been enabled

As soon as I did this I started noticing the benefits of dex-in-process: Build times reduced by around 30 seconds for our project. Sweet!

But wait, if we only need to fit the dex process in the build process, then how about we try the other way around? How about we decrease the memory required by the dex process? Turns out we can. In my setup of 4 gigabytes for dex and 3gigabytes for gradle, I decreased the dex in process down to 1 gigabyte and even the gradle down to 2 gigabytes and I still got dex-in-process enabled and faster builds overall! Less memory, more speed!

Gradle memory >= Dex memory + 1Gb !

Huge amounts of memory, even more gains?

Okay, the question now comes: “What happens if I increase the memory by a lot, will I get even better build times?”. The answer to that is: “nope”. I’ve experimented with values up to 20 gigabytes for the gradle build and 10 gigabytes for the dex in process. It doesn’t look like there’s any real benefit. You should stay at the sensible level of 2–4 gigabytes for gradle and 1–2 for dex.


TL;DR

Dex-in-process speeds up your builds as long as you configure the memory settings for gradle and the dex step properly, so that gradle has at least one gigabyte more than the dex step. This can either happen by increasing the gradle memory requirements, or by reducing the dex step memory requirements.

Quick overview of dex in process