Can I find out what kapt was actually doing In my build scan

Question

Can I find out what kapt was actually doing In my build scan I have 1 12 minutes of `kaptGenerateStubsDevKotlin` even though I only have `kapAndroidTest` `kaptRelease` and `kaptDebug` in my gradle file

wasyl · Answer

Is anything generated in the kapt folders Interesting

darkmoon_uk · Answer

Yes you can enable a `verbose` mode for `kapt` <https kotlinlang org docs reference kapt html>

darkmoon_uk · Answer

In our own case several months back this highlighted outrageously and unexpectedly high processing times in Android Data binding we ended up engaging with DataBinding authors who fixed the issue in v2 engine

Paul Woitaschek · Answer

Where would I pass that `verbose` in android studio

darkmoon_uk · Answer

In `gradle properties` add the line ``` kapt verbose=true ```

Paul Woitaschek · Answer

It s annoying I use dagger reflect everywhere in a custom build type and yet it spends a minute of creating empty folders in the buid dir wink

Paul Woitaschek · Answer

I added that flag but when running gradle i dont find any specific logs on kapt

Dico · Answer

In Kotlin you have all the necessary tools to do DI yourself

Dico · Answer

Without any library

Dico · Answer

It s just passing dependencies to primary constructor properties

Paul Woitaschek · Answer

I dont want to start a discussion on DI I want to know where the kapt tasks come from if I didnt declare them

jw · Answer

Making HTTP requests is just writing bytes to a Socket You don t need a library

Eugen Martynov · Answer

I assume we still need javac even for 100 kotlin code since Dagger generates java code

Eugen Martynov · Answer

Sorry for the offtopic it doesn t help with the original question

wasyl · Answer

< Paul Woitaschek> perhaps you had some tasks up to date It s weird that the task runs and no verbose output is printed Did you try running the relevant assemble task from command line with both verbose kapt and making sure the tasks are run ` gradlew module assembleDev Pkapt verbose=true rerun tasks`

Paul Woitaschek · Answer

Nope there is no output on it But the property itself works it shows stats on the single module that has an annotation processor running room

Paul Woitaschek · Answer

Im giving up there are lots of weird things going on I have only room in a single module and building my highly modularized android application with that single annotation processor takes 7 minutes with 89k lines of kotlin code The longest task is `app mergeDevNativeLibs` even though I dont have any native code at all Even the configuration phase takes 30 seconds disappointed

wasyl · Answer

Build scan doesn t give any hints

wasyl · Answer

That definitely doesn t seem normal

Paul Woitaschek · Answer

Everything just seems to take very long

gildor · Answer

Windows Maybe antivirus Looks like very slow IO Make sense to run gradlr profiler and check what is going on

gildor · Answer

Also check GC time of your build

Eugen Martynov · Answer

Actually GC might be the cause

Eugen Martynov · Answer

from gradle I learned that GC timing should be within 4 of the build time

Paul Woitaschek · Answer

And I get less gc time by allocating more memory 32gb machine

wasyl · Answer

Good place to ask how to figure out which tasks spawn new processes and thus would require custom memory configuration

Eugen Martynov · Answer

For us it was more memory and less workers

gildor · Answer

<https kotlinlang slack com archives C0922A726 p1566840184281000 thread ts=1566807054 253100 amp cid=C0922A726> First check time spent on GC you can find it in build scan if it below 5 or even 10 it will not help Allocating too much memory also will not help

Paul Woitaschek · Answer

Where do I find the GC time in the build scan

wasyl · Answer

Performance gt Build gt Total garbage collection time

Paul Woitaschek · Answer

30 seconds out of 10 09 minutes

Paul Woitaschek · Answer

Maybe that whole story of modularized android applications is a lie and it just slows down everything

gildor · Answer

30 sec looks fine comparing to build time Anyway I think you have some problem with IO or something else it s just looks too slow or you have a lot of code in each module I would try on another machine just for reference and if it s similar tried to profile the build

Paul Woitaschek · Answer

Are there reports on how modularization impacts build time I always find articles saying that it s great for build time but I never heard of an example where a larger app was refactored from being monolithic to a multi module app I have like 80 modules and it s a total failure Even if all tasks are up to date it takes 50 seconds to check that all 1700 tasks created by the Android plugin are up to date

Paul Woitaschek · Answer

Let alone that plus configuring for half a minute

wasyl · Answer

One notable example I know of is twitter app <https www youtube com watch v=rG6nzrRPMRI>

wasyl · Answer

I m not exactly sure how big their app is but I think ~100 modules And their reported build times from 2 years ago after migrating to AGP 3 0 which improved performance quite a lot

gildor · Answer

We have about 150 modules configuration time after some recent fixes of Kotlin plugin is about 5 8 seconds with warm daemob not perfect but not so bad

gildor · Answer

I see that you parallelization is actually not so good a few modules task run essentially without parallelization most of build time But again your build really looks unusually slow

Eugen Martynov · Answer

we have 70 and comparable numbers

wasyl · Answer

Comparable to which numbers Paul s

Paul Woitaschek · Answer

Why does gradle always configure everything

Paul Woitaschek · Answer

If I replace my root `build gradle` with only a single task `tasks register hello ` It throws an exception because all subprojects cant be configured due to the android plugin not applied But why is it even trying to configure everything I thought its supposed to do that on demand

gildor · Answer

Configuration happening every time with or without changes with warm daemon it a bit better because of kit and other caching but by Gradle does configuration every time even if build file is not changed

gildor · Answer

Also configuration on demand is very easy to break it was even discussed to remove this flag which still experimental Essentially if you have one single allprojects on any module or subprojects block configuration on demand is not working by definition also not sure that it even suppose to work if you changes task graph

gildor · Answer

Instant Execution project will help with configuration time but only when you do not change configs As I said a few times try to profile it s much more helpful than just rant about everything it s unusually slow from what you show above

Eugen Martynov · Answer

Gradle has always configuration phase no matter what Until they might change it Try to play with bazel or buck

Paul Woitaschek · Answer

And didn t the android plugin changelog say something about task creation avoidance

Paul Woitaschek · Answer

For me the android plugin alone creates 14 tasks per module `compileDebugAndroidTestJavaWithJavac compileDebugAndroidTestKotlin compileDebugJavaWithJavac compileDebugKotlin compileDebugUnitTestJavaWithJavac compileDebugUnitTestKotlin compileDevJavaWithJavac compileDevKotlin compileDevUnitTestJavaWithJavac compileDevUnitTestKotlin compileReleaseJavaWithJavac compileReleaseKotlin compileReleaseUnitTestJavaWithJavac compileReleaseUnitTestKotlin`

gildor · Answer

gt play with bazel or buck Don t think that it s good advice if you don t have a person who will support this at least part time Bazel and buck have some nice features for really big scale but support of all required tools and just config is not easy Also both of them to get advantage of fast builds require even more aggressive modularization and carefully managed module dependencies graph

gildor · Answer

15 tasks per module is not a problem itself especially with lazy tasks Essentially you should see how many tasks resolved not how many existing Poking some completely random characteristics of your build is not really efficient strategy to improve things

gildor · Answer

gt Until they might change it <https gradle github io instant execution >

jw · Answer

The Android plugin creates a lot more than 14 per module It s closer to 100