Is it possible that dagger is even slower on KSP2 ...

# dagger

[Marek Kubiczek]

Is it possible that dagger is even slower on KSP2 than on KSP? With the recent update of Kotlin (2.1) KSP2 got enabled by default. We observed KSP tasks to run almost twice that long than on KSP. I can't tell 100% sure it's dagger the culprit, but we know that in general dagger takes majority of time in KSP in our project, so it's very likely to be the case.
Explicitly disabling KSP2 brought us back to the previous execution times.

[gildor]

It's possible, yes, at least it was the thing before but we didn't verify performance of the recent versions of ksp2

[Marek Kubiczek]

Thanks, do you know maybe where I can track the progress on dagger KSP support?

[gildor]

Not even sure if it dagger or ksp2 issue, probably both

[Marek Kubiczek]

Oh could be, but why would they enable KSP2 by default then, I hope KSP won't be dropped anytime soon.

[gildor]

To be honest we do not expect anything from dagger anymore and focus on migration to Metro.
Before kotlin-anvil-inject was an option too, but now Metro looks like the most promising solution go, obviously it's at an early stage of development, so not really recommend to do this right now until you want to contribute or at least report bugs

[gildor]

Well, it's a good question, I also think that they shouldn't enable ksp2 so early, see discussion here
https://github.com/google/dagger/issues/2349#issuecomment-2788689734

[Marek Kubiczek]

Ouch, wait, does it mean dagger will stay slow on KSP forever? Never heard about metro.

[gildor]

I don't think so, there is some work to make ksp work better with dagger, but I think the way to monitor it is just check recent dagger releases

[gildor]

fyi https://zacsweers.github.io/metro/

[gildor]

Also, ditching Dagger completely was a plan for Anvil 3
https://github.com/square/anvil/blob/main/docs/ROADMAP.md

Though not sure that Anvil 3 is needed concidering development of metro, hope they combine effort in a single DI tool

[gildor]

See "Breaking from Dagger" section specifically

[gildor]

it also has a part about performance

[gildor]

In our case it's even more painful, because we use Anvil with Dagger, and now Anvil-KSP fork

[Marek Kubiczek]

Thanks. We use dagger + hilt, and we would really like to avoid migration to yet another DI framework.

[gildor]

Well 😄

[gildor]

I think for Kotlin projects it's time to find a better, more integrated solution

[gildor]

again, nothing is really ready yet (at least with our needs), but I think it will be ready way before Dagger will be fast with ksp (which could be never, because it's still bound to Java)

[gildor]

Good thing, that metro already has compatibility layer for Dagger, but not for hilt though

[Michael Montoya]

Alternatively, you can give a try to Koin Annotations, just saying. It is mature, 100% compatible with all the Kotlin ecosystem, and you keep the Annotations processing without the impact on the compilation time.
Obviously I have a biais here 😇

[gildor]

What do you mean by " without impact on the compilation time? if it has ksp, it generates code on compile time, which later have to be compiled, so there is impact on compilation time 😄

[Michael Montoya]

you are right, my bad, I meant without the same impact on compilation time (much less code generated).

[agrosner]

Koin annotations won’t work in a large project since they don’t seem to support anvil/hilt/metro like gradle based DI inclusion. For example you’d need to manually specify all modules in your app project with koin

[Michael Montoya]

Well, actually Koin Annotations is used in very large apps; but the setup is different as you need one @Module class per gradle module, but you can use @ComponentScan to auto-discover components within that module. We also improved the function includes() to help to compose modules hierarchically.
At the end, it is more a pulling than a pushing philosophy.

[Emanuel Moecklin]

At the end, it is more a pulling than a pushing philosophy.

That's the major appeal of Anvil, the pushing part (+ Dagger's optional binding and multi binding). We want to be able to include Gradle modules/sub project and get all the dependencies it provides without changing the consuming module. This gives us the flexibility to assemble different apps with different feature sets very easily (using the build system without code changes).

[Emanuel Moecklin]

It also makes writing deterministic and high fidelity tests much easier. We control what modules contribute to the test, e.g. fake implementations instead of non-deterministic real implementations (api calls, database operations, OS interactions...).