KT-24668 - Kotlin DSL 3-4x slower than Groovy DSL on FIRST USE on many simple projects build

[eskatos]

Groovy DSL ~18s scenario: first use of largeJavaMultiProject template: largeJavaMultiProject performance test results

Kotlin DSL ~75s scenario: first use of largeJavaMultiProjectKotlinDsl template: largeJavaMultiProjectKotlinDsl performance test results

Both with:

• clean checkout
• empty local caches
• cold daemon

The compilation of the 500 build scripts of the example build by the Kotlin compiler dominates wall clock. Note that script compilation is not parallelized in Kotlin nor Groovy.

See the upstream KT-24668 investigation issue.

[JLLeitschuh]

Is this also true with importing into the IntelliJ?

[hansd]

It might be helpful to do a similar measurement with the following parameters:

• warm daemon
• everything has been compiled before
• a change to buildSrc that in my understanding will trigger a full recompile.

[eskatos]

Ways to improve the situation include:

• #753 ~Build-cache for scripts~
• https://github.com/gradle/gradle/issues/9224 Compilation avoidance for scripts
• https://github.com/gradle/gradle/issues/9225 Compiling scripts in parallel
• #201/KT-24668 Optimize Kotlin compiler context reuse

[joshuadeguzman]

Hi @eskatos , I am curious if this issue was already resolved?

[eskatos]

@joshuadeguzman first use is still that slower, dominated by the Kotlin compiler. It could still benefit from parallel compilation and incremental changes to build logic could still benefit from compilation avoidance as linked above.

[joshuadeguzman]

Great! Thank you for the confirmation @eskatos .

[kaushalyap]

@eskatos Any plans to get this done (seems repo is not active)? I think this may be the reason Android Studio Kotlin DSL support lagging behind?

[eskatos]

We have two performance tests running respectively the Groovy DSL and the Kotlin DSL on the same large project for a first use use case:

• Groovy DSL https://builds.gradle.org/repository/download/Gradle_Check_PerformanceSlowCoordinator/27301621:id/report-performance-performance-tests.zip%21/report/tests/first-use-of-largeJavaMultiProject.html?redirectSupported=false
• Kotlin DSL https://builds.gradle.org/repository/download/Gradle_Check_PerformanceSlowCoordinator/27301621:id/report-performance-performance-tests.zip%21/report/tests/first-use-of-largeJavaMultiProjectKotlinDsl.html?redirectSupported=false

Those links (use Login as guest) are for current master branch of Gradle that is ~6.0.

There we can see that the Kotlin DSL build is still ~3x slower than the Groovy DSL build on first use.

Then, on repeated use without changes, this performance test compares Groovy DSL vs. Kotlin DSL:

• Groovy DSL https://builds.gradle.org/repository/download/Gradle_Check_PerformanceTestCoordinator/27277967:id/report-performance-performance-tests.zip%21/report/tests/configure-largeJavaMultiProject.html?redirectSupported=false
• Kotlin DSL https://builds.gradle.org/repository/download/Gradle_Check_PerformanceTestCoordinator/27277967:id/report-performance-performance-tests.zip%21/report/tests/configure-largeJavaMultiProjectKotlinDsl.html?redirectSupported=false

In that use case, we can see that the Kotlin DSL build is ~10% slower than the Groovy DSL build.

That's it for the current state of affairs.

Now on how to make the situation better, my https://github.com/gradle/kotlin-dsl-samples/issues/902#issuecomment-501672404 above still stands.

In any case the best bet to make the situation better across all use cases would be for the Kotlin compiler itself to get faster, this is in JetBrains hands.

Otherwise, compiling the scripts in parallel https://github.com/gradle/gradle/issues/9225 could also make all use cases faster (most probably benefiting to the Groovy DSL too 😃) but this isn't trivial and will require deep changes in Gradle. IOW it'll take time.

The most probable next step is some form of compilation avoidance for Kotlin DSL scripts https://github.com/gradle/gradle/issues/9224 that will make the change in build logic use case faster (not scheduled for now but I'll push for it).

I hope the above clarifies the situation.

[kaushalyap]

@eskatos Thanks for the detailed response!

[mochadwi]

thanks for the detailed explanations @eskatos & an alternative workaround

EDITED:

• after reading from below youtrack, looks like there's a performance improvement for Kotlin 1.3.61

• #201/KT-24668 Optimize Kotlin compiler context reuse