The <alpha release blog post> says `using KAPT and...

# ksp

[elihart]

The alpha release blog post says using KAPT and KSP in the same module will likely slow down your build initially - however, we did some gradle profiling of our own project with KSP enabled and found that mixing KSP/KAPT actually is slightly faster than using only KAPT (if not all processors support KSP)

I’m wondering if there is any more current information about mixing KAPT and KSP in the same module (since alpha release was a while ago), and I’m curious to hear about other people’s experience

[Zac Sweers]

what processors are running in each case?

[Jiaxiang]

Thanks for doing the profiling. The reason we think there is going to be a slow down is because KAPT takes a long time and the best case for mixing is KSP taking minimal time which is still adding extra time to total build. It’s quite interesting to see it’s actually faster though.

[Tyler Hodgkins]

I would assume this would be true in cases where the runtime of the processor itself is larger than the initialization time, assuming KSP performs better than KAPT in general.

[Jiaxiang]

oh, if by mixing means replacing some KAPT processors with KSP processors, then it might be true if the KSP implementation of the processor is faster.

[Jiaxiang]

like leveraging the Sequence can definitely help with performance if used properly

[yigit]

Wow this is very surprising, it could only be explained if the KSP is so much faster than javaP (which would be great:) ).
I've not profiled running KSP and KAPT together. Also room's abstraction cannot benefit from some of the sequence benefits because of a bug in kotlin compiler where it does not report the declarations in the source order

[elihart]

oh, if by mixing means replacing some KAPT processors with KSP processors, then it might be true if the KSP implementation of the processor is faster.

yes, this is what I mean. For example we have two processors in a module and only one supports KSP, we can either run both with KAPT or run one with KAPT and the other with KSP.

what processors are running in each case?

they’re in house processors

[elihart]

I am a little concerned about mixing processors backends in case processors rely on generated sources, but I suppose if it compiles for us it should be fine

[Jiaxiang]

one thing will not work is if one processor is depending on another processor’s generated code.

[elihart]

is that true in both directions (KSP processor relying on code gen from KAPT, or vice versa)? is there any sort of guarantee about which of KSP or KAPT runs first?

[Jiaxiang]

I don’t think there is a guarantee on the order @Ting-Yuan Huang can you confirm on this?

[Ting-Yuan Huang]

KSP and KAPT processors don't see generated sources from each other. There is no order guarantee.

[Ting-Yuan Huang]

Re: performance difference beyond stub generation: I got 2 conjectures.

1. In KAPT, the delegation to javac still builds the full AST and I guess it resolves everything. Although resolution in Java is considerably faster than Kotlin, it still takes time. If a KSP processor only focus on a small part of a large code base, it can be faster.
2. kotlinc reads libraries mainly from metadata, which is much more concise than bytecode. We suspect that this implementation is faster than javac which reads bytecode. So it can be faster if a processor processes a lot of libraries.
If you're using incremental processing, KSP tracks dependencies dynamically while KAPT assumes the worst case. This can be a big difference. Though that currently KSP doesn't track inter-module dependencies (and always reprocess all) while KAPT does. For inter-module changes, KAPT has an edge for now.

[elihart]

Thanks for all the info, that’s great to know!

We only profiled clean builds, but your first theory makes sense because it is a very lean processor that operates only on a small percentage of files within our modules