Many small modules or several large modules for better performance?

A few years ago, when I first adopted gradle for Android (before gradle 2.0), I found that there are some overheads for using and depending on the module, so I stayed away from dividing my project into smaller modules, and instead created very large ones modules. After testing some other build systems (e.g. Buck), performance is achieved by splitting your code into several small modules. Some of the modern programming languages, such as Kotlin, even have visibility modifiers specifically built around the concept of dividing code into modules.

We are currently at gradle 2.14.1 (almost 3.0) level, and for the last few releases they have led to massive productivity gains. With changes to the gradle / Android plugin over the past few years, now it makes faster builds to split your code into smaller modules or use fewer large modules?

+6
source share
1 answer

For both Gradle and Kotlin, there have been big recent gains in compilation performance for general assembly. Including reducing the overhead of several modules in an assembly.

You can see some examples of these increases in this recent article: Cottin and Java Compilation Speed

The overhead between several modules is reduced by combining the Gradle configuration step for modules that are order of magnitude faster and store more in memory, so it does not need to be reloaded with every compilation run, rather than compiling that fine-grained dependency checking does not need to be recompiled.

Here are some tips:

  • make sure the Gradle daemon is enabled (by default now, so if you haven’t disabled it, everything is fine)
  • upgrade to Kotlin 1.0.3 (and follow release 1.0.4 soon)
  • enable incremental compilation of Kotlin :

    To enable incremental compilation for Gradle, you need to set the kotlin.incremental property to true (for example, by adding the line kotlin.incremental = true to the gradle.properties file in the root directory of your project).

  • use Android studio 2.1 or later and enable DEX in the process

    Android Studio 2.1 includes a new feature: Dex In Process, which can significantly increase the speed of complete clean builds, as well as improve the performance of Instant Run.

  • make sure that any tasks you use support incremental launch in Gradle, some of them cannot and can slow down the build time (for example, the Dokka task is executed no matter what has changed), you can disable tasks that you do not need use the -x<task> parameter for gradle all the time.

Now, whether it's faster for multi-module assemblies or assembling a single module, I have found that the overhead for modules that have not changed is negligible. And for those that are, this is the usual cost of compiling.

Remember that incremental compilation does not always work between Android installations in Gradle due to the Android plugin for Gradle changing cluster order between assemblies . Although this tends to be consistent between assemblies, it is likely that if he recounts the class path, it will be a different order and will cause a new complete assembly. But this will be a problem, be it one or more modules.

The general answers to your question probably vary greatly in designs, hardware, different configurations and perceptions of people, and even misuse and misconfiguration of assemblies. Given the improvements mentioned above, you should decide to take the time to check the current status of your actual project - and see for yourself!

+2
source

All Articles