How does KTS perform compared to Groovy scripts?

preface

The Android Gradle plugin 4.0 supports the use of Kotlin scripts (KTS) in Gradle build configurations. Used as an alternative to Groovy, the programming language used in Gradle configuration files. KTS is better for writing Gradle scripts than Groovy because code written in Kotlin is more readable, and Kotlin provides better compile-time checking and IDE support.

However, the document also notes that while KTS is currently better integrated into Android Studio’s code editor than Groovy, builds with KTS tend to be slower than with Groovy, so build performance should be considered when migrating to KTS.

So how does KTS perform compared to Groovy? For everyone to decide whether to migrate to KTS to provide certain reference

KTSPerformance analysis

Performance analysis tool

To analyze THE performance of KTS, we first need to measure the compile time consistently. The compile speed can be affected by many factors, such as build cache, so it is difficult to measure the impact of KTS plug-ins on performance

Performance can be accurately measured using Gradle Performance Profiler, a tool for gathering performance analysis and benchmarking analysis information for Gradle builds. With the Gradle performance profiler, you can create build scenarios and run them multiple times to prevent excessively different results and ensure reproducibility of the results.

Part of the project configuration for benchmarking analysis includes:

• The plug-in version
• Gradleversion
• JVMSettings (heap size, permanent generation size, garbage collection, etc.)
• GradleNumber of workers (org.gradle.workers.max)
• Click on plug-in options to further optimize performance

For example, if we need to benchmark clean builds, you can create a scenario for gradle-Profiler execution:

# <root-project>/scenarios.txt
clean_build {
    tasks = [":app:assembleDebug"]
    cleanup-tasks = ["clean"]
}
Copy the code

To run this scenario, use the following command:

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt
Copy the code

With the above commands, you can run Clean Build multiple times and generate a Clean Build performance report. In addition to clan builds, Gradle-Profiler can also perform performance analysis for incremental builds, different gradle plugin versions, and different memory /CPU levels. With the gradle-profile command, build scenarios can be created and run multiple times, preventing the results from being too different and ensuring reproducibility of the results to help us better analyze performance. For details on how to use Gradle-Profile, see the documentation: Analyzing Build Performance

Gradle 6.8Version Performance Analysis

For Gradle 6.8, we analyze KTS performance from the following four use cases

• First run (that is, clear allbuild cache)
• buildSrc abiChanged (supportedabiMost of the cache is invalidated and most of the code needs to be recompiled.
• buildSrc 非 abiChange (i.e.,buildSrcGeneral modification in)
• There is no change

The following data is from a performance test run on Gradle CI. These tests were run in a large project with a large number of subprojects, and they were run on Groovy and Kotlin DSL for comparison purposes.

As you can see, Groovy scripts still have some performance advantages

1. On the first run,Groovy DSLthanKTSfast2.2times
2. inbuildSrc abiChange,Groovy DSLthanKTSfast3.2times
3. inbuildSrcnonabiChange,KTSthanGroovyfast2.5times
4. When the code does not change, the performance is similar

As you can see, KTS only has a performance advantage with non-ABI changes. This is because groovy changes in buildSrc make the entire project obsolete, causing the project to be recompiled, while KTS changes in buildSrc can skip compilation of unaffected build script files. So when we modify Buildsrc, KTS builds much faster than groovy plug-ins

The above data from: builds.gradle.org/buildConfig… , you can log in to view the information in visitor mode

Gradle 7.4Version Performance Analysis

For Gradle version 7.4, we analyzed KTS performance through the following three use cases

• First run (that is, clear allbuild cache)
• buildSrc abiChanged (supportedabiMost of the cache is invalidated and most of the code needs to be recompiled.
• buildSrc 非 abiChange (i.e.,buildSrcGeneral modification in)

As you can see, KTS compilation performance has improved for Gradle 7.4, reducing the performance gap to about 1.5 times

conclusion

Overall, KTS has huge advantages over Groovy in terms of readability, ease of use, compile-time checking, and IDE support, but has some disadvantages in terms of performance, as follows:

• forGradle 6.8Version, if the cache is mostly invalid or there is no cache,Groovy DSLthanKTSfast2to3times
• Gradle 7.4versionKTSPerformance is improved. If most of the cache fails or there is no cache,Groovy DSLthanKTSfast1.5Times the left and right sides.
• whenbuildSrcOccurs in theabiChange,ktsScript compile ratioGroovy DSLfast4to5Times, that’s becausebuildSrcIn thektsYou can skip compilation of unaffected build scripts, whilegroovyTemporary does not support
• When no changes have been made to the project,KTSwithGroovy DSLNot much difference in compile speed

KTS has both advantages and disadvantages in terms of ease of use and performance. Gradle is also in the process of optimization. You can decide whether to migrate your build configuration from Groovy to KTS based on your own project situation

The resources

The Kotlin and Groovy DSLs should have similar performance characteristics