Are the linking times going to be shorter with the Kotlin 1.7.20 release?

# kotlin-native

[napperley]

Are the linking times going to be shorter with the Kotlin 1.7.20 release?

[napperley]

@Pavel Kunyavskiy [JB] - Some Unit testing was done recently, and it was found that the linking time is the biggest bottleneck (really slows down the tests). Linking time is so long ("molasses slow") for testing that in some cases it is significantly quicker to do testing via Kotlin Playground instead (true story) 😱 .

[Pavel Kunyavskiy [JB]]

Comparison with Playground is strange. As I remember it doesn’t support Kotlin/Native, so you can just use kotlin-jvm locally with the same result. As for 1.7.20, we are working on that, but it is the work with small incremental improvements, not some breakthroughs.

Also, are you talking about debugging or optimized build? Do you have build caches enabled (probably yes, if you are using default settings on primary targets in debug mode)? Can you please run the build with -Xprofile-phases option? It will print which parts of the build are slow. Unfortunately, in most cases, the llvm part is the slowest one, and we don’t have much to do with it, although there are some long-term ideas.

[Landry Norris]

The new mm forces us to disable build caches, which is what led to a jump in build times for our project. I did notice that 1.7.20 will allow build caches with the new mm, however, which is promising.

[napperley]

Although Playground doesn't support K/N it does support the Kotlin Standard library, which is available for K/JVM & K/N. The test code was developed on both sides (Playground & K/N) and it just uses the Kotlin Standard library, therefore the build times can be compared.

[Landry Norris]

Could you add jvm support and run jvm tests since it's using the stdlib?

[napperley]

That could be done although it would create a bit of a mess (the project backend targets linuxX64 with plans to include Linux ARM targets), and is only a temporary short term solution. In the medium to long term the new Kotlin compiler would need to be released, and have some special linker optimisations for Kotlin Native programs that cut down the linking times significantly.

[ephemient]

sure, but even with future improvements I don't expect native link times to be competitive with JVM link times

[napperley]

The JVM application build process doesn't have a linking step, unless GraalVM is used via its AOT mode.

[ephemient]

exactly, doing nothing is faster than doing something. also even if you include runtime, JVM classloading is completely on-demand so it is linking less than a native build