every code change disappointed ``` 73ms app mergeDevDebugRes

Question

every code change disappointed ``` 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 confused

mg6maciej · Answer

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

uhe · Answer

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

mg6maciej · Answer

What libs do you use

mg6maciej · Answer

You mean your own libs

uhe · Answer

butterknife android state dagger 2 and paper parcel

uhe · Answer

those 4 need kapt

mg6maciej · Answer

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

adibfara · Answer

why have you enabled proguard in debug build

masc3d · Answer

why butterknife when having kt android extensions

rwachol · Answer

java support

uhe · Answer

because of the method limit

uhe · Answer

and butterknife because historic reasons

uhe · Answer

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

uhe · Answer

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

masc3d · Answer

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

masc3d · Answer

but just in case I have settled with Kodein <https salomonbrys github io Kodein > for injection

masc3d · Answer

and <https github com tinsukE icekick> for state

masc3d · Answer

maybe it helps

uhe · Answer

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

uhe · Answer

will have a look at icekick thanks

spierce7 · Answer

Kodein has bad performance Like it s pretty bad

spierce7 · Answer

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

adibfara · Answer

< spierce7> what s wrong with dagger

rwachol · Answer

better question is what s wrong with kapt wink it doesnt always work is slow

mg6maciej · Answer

I also have my own veeery simple DI microframework

mg6maciej · Answer

Just for overriding stuff I can t control in UI tests

deviant · Answer

<https kotlinlang slack com archives android p1488424037005445 thread ts=1488386854 005378 amp 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 · Answer

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

spierce7 · Answer

< adibfara> Nothing is wrong with dagger except that it s a bit ugly in kotlin and requires annotation processing

spierce7 · Answer

other than that it s spectacular

spierce7 · Answer

< 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 · Answer

adibfara · Answer

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 · Answer

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 lt String gt and List lt Integer gt My solution can t It see s all List s as the same

spierce7 · Answer

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 · Answer

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 · Answer

well for me total build time is not that bad `Total time 1 mins 33 179 secs`

rwachol · Answer

< adibfara> if I dont change anything it s 6 sec if I change java file it s 10 sec

masc3d · Answer

< 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