Tips for improving Kotlin/Native compilation times
The Kotlin/Native compiler is constantly receiving updates that improve its performance. With the latest Kotlin/Native compiler and a properly configured build environment, you can significantly improve the compilation times of your projects with Kotlin/Native targets.
Read on for our tips on how to speed up the Kotlin/Native compilation process.
Use the most recent version of Kotlin. This way you will always have the latest performance improvements.
Avoid creating huge classes. They take a long time to compile and load during execution.
Preserve downloaded and cached components between builds. When compiling projects, Kotlin/Native downloads the required components and caches some results of its work to the
$USER_HOME/.konandirectory. The compiler uses this directory for subsequent compilations, making them take less time to complete.
When building in containers (such as Docker) or with continuous integration systems, the compiler may have to create the
~/.konandirectory from scratch for each build. To avoid this step, configure your environment to preserve
~/.konanbetween builds. For example, redefine its location using the
The first compilation with Gradle usually takes more time than subsequent ones due to the need to download the dependencies, build caches, and perform additional steps. You should build your project at least twice to get an accurate reading of the actual compilation times.
Here are some recommendations for configuring Gradle for better compilation performance:
Increase the Gradle heap size. Add
gradle.properties. If you use parallel builds, you might need to make the heap even larger or choose the right number of threads with
Build only the binaries you need. Don't run Gradle tasks that build the whole project, such as
assemble, unless you really need to. These tasks build the same code more than once, increasing the compilation times. In typical cases such as running tests from IntelliJ IDEA or starting the app from Xcode, the Kotlin tooling avoids executing unnecessary tasks.
If you have a non-typical case or build configuration, you might need to choose the task yourself.
linkDebug*: To run your code during development, you usually need only one binary, so running the corresponding
linkDebug*task should be enough. Keep in mind that compiling a release binary (
linkRelease*) takes more time than compiling a debug one.
packForXcode: Since iOS simulators and devices have different processor architectures, it's a common approach to distribute a Kotlin/Native binary as a universal (fat) framework. During local development, it will be faster to build the
.frameworkfor only the platform you’re using.
To build a platform-specific framework, call the
packForXcodetask generated by the KMM project wizard.
Don’t disable the Gradle daemon without having a good reason to. Kotlin/Native runs from the Gradle daemon by default. When it’s enabled, the same JVM process is used and there is no need to warm it up for each compilation.
Use the Gradle build caches:
Local build cache: Add
gradle.propertiesor run with
--build-cacheon the command line.
Remote build cache in continuous integration environments. Learn how to configure the remote build cache.
Use the compiler caches. Starting from 1.5.0-M1,
iosArm64targets have experimental opt-in support for compiler caches. They improve compilation times for debug builds (for
linuxX64, this feature is only available on Linux hosts). To enable the compiler caches, add
The following targets already have the compiler caches enabled by default:
Enable previously disabled features of Kotlin/Native. There are properties that disable the Gradle daemon and compiler caches –
kotlin.native.cacheKind=none. If you had issues with these features before and added these lines to your
gradle.propertiesor Gradle arguments, remove them and check whether the build completes successfully. It is possible that these properties were added previously to work around issues that have already been fixed.