https://kotlinlang.org logo
Join Slack
Powered by
Is there a commitment to improve kotlin gradle dsl...
# gradle
b
Is there a commitment to improve kotlin gradle dsl performance? I'd love to switch to it just for the developer productivity boost of using 
cmd+b
to see where a dependency version var is defined in a project with many modules. I am not sure that the dev productivity boost outweighs the marginal slowdown in compile time. And when major open source kotlin repositories (eg coroutines) are not using the dsl it signals that there is not even confidence within jetbrains around using it. You can 
ctrl+j
for documentation lookup but there is little-to-no documentation of the dsl-ified version of the android plugin, and often the function signatures are not informative.
o
https://github.com/Kotlin/kotlinx.coroutines/issues/1938 seems to indicate that they are pushing towards using the DSL and https://github.com/JetBrains/kotlin uses it as well, so I don't think Jetbrains is shying away from it
šŸ‘Œ 1
I think that the Gradle team is still pushing for more performance, but the difference to groovy might be more marginal than you think -- I don't have benchmarks, but I bet that the static nature of Kotlin is much faster than the dynamic Groovy for executing the scripts, even if it is a little slower to compile, and since the compilation is cached it might add up to less time overall
b
I found a github issue tracking performance benchmarks over the last year a while back. I'll dig it up and link here.
"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... In that use case, we can see that the Kotlin DSL build is ~10% slower than the Groovy DSL build."
o
first use is still much longer, but I think that mostly has to do with the generation of the accessors JAR, which is shared for every project using the same version of Gradle, so it's really not that big of a deal after one build. I wouldn't worry about it too much, compared to tens/hundreds of times you're executing gradle after that
šŸ‘ 1
c
In most projects, youā€™re changing code far more frequently that you do its build scripts. But when you do change the build scripts, itā€™s much better for me to actually be able to click into it and make sure Iā€™m doing it right. With Groovy, youā€™re mostly left hoping that the pluginsā€™ documentation is up-to-date and complete (which is not always the case). The slight hit to performance is well worth the benefits, IMO. I honestly donā€™t feel like I ever really understood Gradle beyond the surface-level until I started migrating my scripts to Kotlin DSL, and my builds still feel just as snappy in day-to-day development.
Just make sure your project has the build cache enabled, as changes to scripts invalidate the entire project. But youā€™ll spend more time waiting for the project caches to be rebuilt than you will on Gradleā€™s performance itself, and the build cache greatly helps with that https://docs.gradle.org/current/userguide/build_cache.html
o
yes, I spent a ton of time digging into Gradle source code to figure out the magic of Groovy when migrating to Kotlin DSL, I think it's much nicer for building a model of how things work
e
When nothing has changed, Groovy vs. Kotlin performance is quite similar. The main difference is with the actual compilation of the Kotlin scripts. Itā€™s ~3 times slower than Groovy.
The accessors generation isnā€™t the culprit, itā€™s damn fast as we generate the bytecode directly, bypassing the Kotlin compiler.
The bottleneck is the Kotlin compiler. 1.4, or 1.4.1, promises a much faster compiler, this will change the picture.
o
interesting, perhaps that's just because I have such a small set of scripts that the accessor gen for initial gradle setup seems like it takes ages
e
Ah right, thatā€™s something different. When you change Gradle version, Kotlin extensions for the whole Gradle API get generated, and they are compiled using the Kotlin compiler. Can take a while yes šŸ˜•
z
Link on the compiler speed? Curious to read more
e
It was announced at KotlinConf. Thereā€™s some information here https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/
Subject starts here in the keynote

https://youtu.be/0xKTM0A8gdI?t=1201ā–¾

The ā€œnot in 1.4ā€ means ā€œin 1.4.xā€
ā€œaiming at a factor 5ā€
Is that what you were looking for @Zac Sweers?
z
Ah yep I completely forgot about the first part of that šŸ˜…
Exciting stuff
e
Indeed!
c
i think there is newer documentation that states that the improved compiler speed is not coming in 1.4.x
e
hum šŸ˜• any pointer @christophsturm?
c
actually i searched and found nothing, but i remember a jetbrains employee saying here in this slack that the new compiler will not be enabled in 1.4 timeframe. the webpage you posted also says ā€œnot in 1.4ā€.
e
c
cool. thats what i was searching for but I did not find it
e
Iā€™m confident Kotlin folks will make it fast eventually. But itā€™s a bit sad weā€™ll have to wait more.
b
Is that meant to read as the new compiler frontend will not be ready until at least 1.6?
c
i read it as not ready until at least 1.5 and possibly 1.6
but i think i also read that parts of the new compiler will be merged continously
e
I guess there will be some steps yeah. Maybe we can hope for experimental performance improvements in 1.5 stabilized towards 1.6
8 Views
Open in Slack
PreviousNext
Powered by