I agree that my perspective is very skewed because I mostly use Gradle for Android and the AGP/Android toolkit team has not been very proactive. But many of these problems still carry over to non-Android JVM projects I've worked on. The build times are still noticeably slower than Groovy and the code complexity arising from every plugin author not being able to afford being proactive in migrating their codebases. I really, really enjoy working with Kotlin and I would love to be able to write everything in Kotlin but as Howard Stark would say ;)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
But many of these problems still carry over to non-Android JVM projects I've worked on.
Yes but fixes are coming.
A pain point for me in IntelliJ IDEA is that auto-completion in build.gradle.kts, while great, is also quite slow.
Well, once Kotlin 1.3.60 is released, it is supposed to be 3 times faster.
The build times are still noticeably slower than Groovy
This is also a problem that can be solved... but only if tackled properly. Talking about performance in general is nonsense.
What you should do a Gradle Build Scan and check there is nothing wrong with your build configuration and see what metrics do you have.
Well, once Kotlin 1.3.60 is released, it is supposed to be 3 times faster.
That's great to hear.
What you should do a Gradle Build Scan and check there is nothing wrong with your build configuration and see what metrics do you have.
I have. My configuration had no bottlenecks, Kotlin just took longer to compile than Groovy, and the build scan results for the tasks after the initial compilation of configuration files were nearly identical.
I've taken most standard measures to maximise system performance, I disabled Spectre and Meltdown mitigations on my AMD machines, I've disabled all daemons and services I don't require.
I've tried with and without Gradle build cache and the results have not changed, once configured with the Kotlin DSL, there is a noticeable if not significant degradation in build times.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Not using buildSrc on this particular project. Used it extensively on the Android project where I got 5 to 10 seconds of slowdowns. I don't modify it during most iterative development, only for dependency updates and version bumps where I don't use or build from an IDE.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
In this project you are using my old plugin de.fayard.buildSrcVersions
I noticed exactly the same problem as you: modifying Versioons.kt is not great because it basically forces a clean build every time.
Instead I am now working on de.fayard.refreshVersions that does the same thing, but extract the versions not in code (inside the buildSrc) but in a proper format (that can be read and written by tools) so that we don't pay the penalty price on each update.
I agree that my perspective is very skewed because I mostly use Gradle for Android and the AGP/Android toolkit team has not been very proactive. But many of these problems still carry over to non-Android JVM projects I've worked on. The build times are still noticeably slower than Groovy and the code complexity arising from every plugin author not being able to afford being proactive in migrating their codebases. I really, really enjoy working with Kotlin and I would love to be able to write everything in Kotlin but as Howard Stark would say ;)
Yes but fixes are coming.
A pain point for me in IntelliJ IDEA is that auto-completion in
build.gradle.kts
, while great, is also quite slow.Well, once Kotlin 1.3.60 is released, it is supposed to be 3 times faster.
This is also a problem that can be solved... but only if tackled properly. Talking about performance in general is nonsense.
What you should do a Gradle Build Scan and check there is nothing wrong with your build configuration and see what metrics do you have.
The one Gradle trick that supersedes all the others
Jean-Michel Fayard γ» Sep 22 γ» 3 min read
That's great to hear.
I have. My configuration had no bottlenecks, Kotlin just took longer to compile than Groovy, and the build scan results for the tasks after the initial compilation of configuration files were nearly identical.
I've taken most standard measures to maximise system performance, I disabled Spectre and Meltdown mitigations on my AMD machines, I've disabled all daemons and services I don't require.
I've tried with and without Gradle build cache and the results have not changed, once configured with the Kotlin DSL, there is a noticeable if not significant degradation in build times.
I wonder, are you using the
buildSrc
and modifying it frequently?Not using buildSrc on this particular project. Used it extensively on the Android project where I got 5 to 10 seconds of slowdowns. I don't modify it during most iterative development, only for dependency updates and version bumps where I don't use or build from an IDE.
Ah ah, that part looks very familiar.
In this project you are using my old plugin
de.fayard.buildSrcVersions
I noticed exactly the same problem as you: modifying
Versioons.kt
is not great because it basically forces a clean build every time.Instead I am now working on
de.fayard.refreshVersions
that does the same thing, but extract the versions not in code (inside thebuildSrc
) but in a proper format (that can be read and written by tools) so that we don't pay the penalty price on each update.See github.com/jmfayard/buildSrcVersio...
Subscribed to the issue :)