every code change :disappointed: ``` 73ms :a...

# android

[uhe]

every code change 😞

73ms  :app:mergeDevDebugResources
     53ms  :app:processDevDebugManifest
  28678ms  :app:kaptDevDebugKotlin
   1812ms  :app:compileDevDebugKotlin
   7043ms  :app:compileDevDebugJavaWithJavac
   1479ms  :app:copyDevDebugKotlinClasses
   8729ms  :app:transformClassesAndResourcesWithProguardForDevDebug
   4255ms  :app:transformClassesWithDexForDevDebug
   1828ms  :app:packageDevDebug

while annotation processing is cool in principle the performance hit really hurts 😕

[mg6maciej]

uhe: Wow. This is huge. I'm glad I don't use APT.

[uhe]

Yeah, sucks a bit. But I'm too deeply invested in our various libs to just not use it.

[mg6maciej]

What libs do you use?

[mg6maciej]

You mean your own libs?

[uhe]

butterknife, android-state, dagger 2 and paper-parcel

[uhe]

those 4 need kapt

[mg6maciej]

Yeah, that would be a lot of code to modify if you wanted to remove kapt.

[adibfara]

why have you enabled proguard in debug build?

[masc3d]

why butterknife when having kt android extensions?

[rwachol]

java support ?

[uhe]

because of the method limit

[uhe]

and butterknife because ... historic reasons

[uhe]

when we last tried android extension they didn't really work in all our cases

[uhe]

might have changed tho... maybe I'll give them another try some time

[masc3d]

not sure if you consider moving away from kapt, as I did

[masc3d]

but just in case, I have settled with [Kodein](https://salomonbrys.github.io/Kodein/) for injection

[masc3d]

and https://github.com/tinsukE/icekick for state

[masc3d]

maybe it helps..

[uhe]

I've thought about using Kodein but we have huge dagger modules... would probably take quite some time to migrate

[uhe]

will have a look at icekick, thanks

[spierce7]

Kodein has bad performance. Like it's pretty bad.

[spierce7]

I ended up rolling my own dependency injection for Kotlin that was a ton more performant

[adibfara]

@spierce7 what's wrong with dagger?

[rwachol]

better question is, what’s wrong with kapt 😉 (it doesnt always work / is slow)

[mg6maciej]

I also have my own, veeery simple DI microframework.

[mg6maciej]

Just for overriding stuff I can't control in UI tests.

[deviant]

https://kotlinlang.slack.com/archives/android/p1488424037005445?thread_ts=1488386854.005378&cid=C0B8M7BUY

really? could you give us more details? i thought it uses property delegates which is nothing more than just sugar. and should be pretty fast.

[masc3d]

yes. I would be curious to hear about those details as well.

[spierce7]

@adibfara Nothing is wrong with dagger, except that it's a bit ugly in kotlin, and requires annotation processing.

[spierce7]

other than that, it's spectacular.

[spierce7]

@deviant @masc3d You can see some of the benchmarking I did vs dagger, kodein, and the start of my own dependency injection system I rolled based on kodein's API

[spierce7]

https://github.com/ScottPierce/kotlin-android-di-benchmark

[adibfara]

I currently use dagger on kotlin in a big project , haven't had a problem with it.What is the expected build time (incremental) for you guys? For me with this project, it's about 5-10s each incremental build

[spierce7]

I gave up a few things when I rolled my own, that kodein has. Kodein can inject based on Generics. i.e. It can tell the difference between List<String> and List<Integer>. My solution can't. It see's all List's as the same.

[spierce7]

To be clear, I'm not suggesting you use my DI solution. The one posted in that has some bugs I believe that I've sorted out now. Point is that Kodein has bad performance, which is why I steered away from it. I brought it up with them, and the creator made a separate API that was more performant, but I find it annoying that I have to use a separate API consistently to get the performance I expect. Plus I found that Kodein had an annoying number of features.

[spierce7]

Kodein has bad performance because on each injection, it uses reflection to determine if there are any generic classes, and it's essentially generating a Java Type similar to how gson uses TypeTokens.

[rwachol]

well, for me total build time is not that bad Total time: 1 mins 33.179 secs

[rwachol]

@adibfara if I dont change anything it’s 6 sec, if I change java file it’s 10 sec

[masc3d]

@spierce7 thanks that’s interesting. there’s kodein-erased now if you don’t need generics, but even that is still at least 10 times slower than yours or even dagger.