https://kotlinlang.org logo
Title
b

Brendan Weinstein

06/15/2020, 9:45 PM
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

octylFractal

06/15/2020, 9:50 PM
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

Brendan Weinstein

06/15/2020, 9:53 PM
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."
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

Casey Brooks

06/15/2020, 10:32 PM
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

octylFractal

06/15/2020, 10:34 PM
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

eskatos

06/16/2020, 6:00 AM
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

octylFractal

06/16/2020, 6:07 AM
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

eskatos

06/16/2020, 6:28 AM
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

Zac Sweers

06/16/2020, 6:58 AM
Link on the compiler speed? Curious to read more
e

eskatos

06/16/2020, 7:00 AM
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

Zac Sweers

06/16/2020, 7:12 AM
Ah yep I completely forgot about the first part of that 😅
Exciting stuff
e

eskatos

06/16/2020, 7:12 AM
Indeed!
c

christophsturm

06/16/2020, 10:39 AM
i think there is newer documentation that states that the improved compiler speed is not coming in 1.4.x
e

eskatos

06/16/2020, 12:29 PM
hum 😕 any pointer @christophsturm?
c

christophsturm

06/16/2020, 12:32 PM
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”.
c

christophsturm

06/16/2020, 12:35 PM
cool. thats what i was searching for but I did not find it
e

eskatos

06/16/2020, 12:37 PM
I’m confident Kotlin folks will make it fast eventually. But it’s a bit sad we’ll have to wait more.
b

Brendan Weinstein

06/16/2020, 4:11 PM
Is that meant to read as the new compiler frontend will not be ready until at least 1.6?
c

christophsturm

06/16/2020, 6:17 PM
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

eskatos

06/17/2020, 1:15 PM
I guess there will be some steps yeah. Maybe we can hope for experimental performance improvements in 1.5 stabilized towards 1.6