so Room is getting close to adding KSP support suc...
# ksp
y
so Room is getting close to adding KSP support such that i was able run a compile time comparison between kapt and ksp (for room kotlin integration testapp). tl;dr; using KSP makes it ~50% faster 🙂 To my surprise, even the ksp task is faster than kapt's processing step (without stubs). This is not very scientific so i might be doing something wrong but these are very encouraging numbers
Copy code
script used:
<https://android-review.googlesource.com/c/platform/frameworks/support/+/1531924/11/room/ksp-kapt-comparison.sh>
10 runs (clean compile test app):
 
total time spent in each group's tasks:
kapt : 34584 ms
ksp : 18671 ms
 
individual task totals:
kaptGenerateStubsDebugAndroidTestKotlin : 11751 ms
kspDebugAndroidTestKotlin : 17400 ms
kaptDebugAndroidTestKotlin : 21407 ms
kaptAndroidTestDebug : 0 ms
kapt : 0 ms
kaptAndroidTest : 41 ms
kspDebugKotlin : 1225 ms
kaptGenerateStubsDebugKotlin : 799 ms
kaptDebugKotlin : 586 ms
ksp : 46 ms
kaptDebug : 0 ms
🎉 16
❤️ 5
s
Have you guys added incremental compilation support?
How maintainable is the code you’ve written for KSP vs the compiler plugin?
y
KSP supports incremental but we've not updated to that version yet due to another bug. but even after that, we'll need to do some work before supporting incremental compilation.
in terms of maintainability, i don't have a good answer because i've not written a compiler plugin (aside from KSP contributions). From Room's perspective, we have an abstraction that has KSP and JAVA AP implementations. it is reasonably maintainable. It is not trivial code as we need to do what KAPT does (view kotlin source code as if it is java) which adds significant complexity on the abstraction (e.g. adding a new parameter for suspend functions, reporting methods for property getters/setter etc). but from Room's processing APIs, it is invisible, which is the good part
if curious, this is the abstraction: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/compiler-processing/ it is very specific to room such that we only support what we need but i keep going back and forth whether we might want to use it outside room. It is possible that we might use it for dagger/hilt but right now, dagger has APIs that uses java elements so them moving to an abstraction is not trivial. for now, i'm solely focused on making this work for room. I'm sure we'll find lots of bugs when we ship, our kotlin integration tests are very limited to just testing kotlin specific stuff.
👍 2