Re-profiled our builds with KSP2 with 2.0.21-1.0.27. Unfortunately, across the board in a bunch of b...

# ksp

[Zac Sweers]

Re-profiled our builds with KSP2 with 2.0.21-1.0.27. Unfortunately, across the board in a bunch of benchmarks I found that

• abi change - KSP2 is ~40-50% slower
• noabi change - KSP2 is 80-100% slower
• clean build - negligible/amortized by the clean build
If I just benchmark expensive our two most expensive KSP tasks with --rerun, KSP2 is around 20-30% slower. Not to mention - dagger-ksp continues to not work in KSP2.

Pretty worried about KSP2's viability come Kotlin 2.1.0 😕

[elihart]

Thanks for sharing that Zac. I suppose this is taking into account KSP moving from the kotlin to gradle daemon and adjusting memory accordingly?

[Zac Sweers]

we give the kotlin and gradle daemons the same memory, and these benchmarks were run on overpowered AWS boxes

[Zac Sweers]

none of these builds were experiencing memory pressure with the settings they had (somewhere in the dozens of GB for xmx)

[elihart]

Yep, figured, just wanted to double check.

And I was hoping KSP2 would have better performance by taking advantage of K2 😮‍💨

[elihart]

Hopefully after the bug fixing phase is over they can focus on some perf optimizations

[Zac Sweers]

it's not really taking advantage of K2 in the same way though

[Zac Sweers]

it's running on the kotlin analysis API and is just a CLI under the hood

[Zac Sweers]

kapt actually was doing the same and abandoned it because the performance was not good enough 😬, that's why they switched back to a KAPT3-style approach in kotlin 2.1.0

[elihart]

ah, I thought maybe the analysis API was faster with K2…

[Zac Sweers]

performance is eventually the goal but first goal atm was more oriented around functionality

[Zac Sweers]

but I worry in the context of kotlin only supporting n+1 forward compatibility. If you use KSP1 you have to target kotlin 1.9, and presumably with kotlin 2.1 you start running into problems depending on newer libraries built against 2.1

[elihart]

yeah, that’s a good point.

[Oleg Yukhnevich]

it's not really taking advantage of K2 in the same way though

curious, why do you say/think so?

[Zac Sweers]

in KSP1 it was just a KotlinCompile task and leaned on all the same toolchain infrastructure. In KSP2 it's calling a completely different API that sits on top of FIR but is not benefitting from the rest of the toolchain (no kotlin daemon, no hot classloaders, etc)

[Zac Sweers]

(but correct me if I'm misunderstanding something!)

[Oleg Yukhnevich]

Yeah, from that point of view it might be slower...
But still, it uses the same new frontend (FIR) as the K2 compiler, so in the end it should be faster than before (both for KSP and Dokka)
I think that part with no kotlin daemon, no hot classloaders probably could be somehow amortized by using Gradle workers - though I'm mostly speculating

Curious though, how much this KSP2 overhead adds to the overall compilation step? E.g time-to-run?

[Zac Sweers]

time-to-task-start is more or less the same, assumes a hot configuration cache

[Zac Sweers]

Here's a few samples. Looking again there is some GC time creeping into some of these that I'll look closer into, but not enough to majorly skew the larger trend

[Zac Sweers]

Filed this for referencing: https://github.com/google/ksp/issues/2282