To combat this situation we wanted to make it easier for everyone to understand and measure how build configuration changes (e.g. enabling dex-in-process for our project) or application modularization can affect our builds times for better or worse. Understanding your build times is not as easy as it sounds:

You need to run a build many times to get an average, which means you need to get the calculator out and add the numbers yourself 😅.

Typically you need to run this on your dev machine.

Using your dev machine for anything while benchmarking might affect the results.

Any unrelated process running in the background might affect the results as well.

Introducing Gradle Profiler

Looking around we quickly found the Gradle Profiler project. With this tool, you can do 2 things, benchmark and profile a build.

From the library documentation:

“Benchmarking simply records the time it takes to execute your build several times and calculates a mean and standard error for it. It has zero impact on the execution time, so it is ideal for making before/after comparisons for new Gradle versions or changes to your build”.

While for profiling:

“Profiling allows you to get deeper insight into the performance of your build. The app will run the build several times to warm up a daemon, then enable the profiler and run the build.”

So to sum things up, if you are after timings for your Gradle build then you should run your build against the tool using the benchmark option, while if you want to get insights about the CPU utilisation, memory allocation, etc. then you should run it with the profile option. For this article, we’ll focus on benchmarking as we are after some timings for our builds, and not really insights on why things take as long as they do (without saying that this is not an interesting insight as well).

To run a benchmark, you first need to check out the gradle-profiler project and run the following command:

./gradlew installDist

which will install the gradle-profiler executable into ./build/install/gradle-profiler/bin . The next step is to run the following:

gradle-profiler --benchmark --project-dir <root-dir-of-build> <task>