Jerome will do that for you :)

Bingran, can you have a look at this asap. thx !

To make sure I analyze the "buildOnServer-7.5-rc-2-2022-07-01-shutdown.snapshot" correctly, I attached a screenshot of how I find the concerning point. From the picture, the MergeGeneratedProguardFilesCreationAction takes 1924ms. Is that the right way to check your snapshot file? If so, what is the expected time for that creation action in a config cached build?

I think you missed adding an attachment.

oops, here it is =)

From discussions with xav@ that time should almost be non-existent during the run when the configuration cache kicks in.

I checked out androidx-main, is that the right one? There is no gradlew file under that directory.

bingran@bingran-linux-west:~/androidx-main/tools$ ls
external  fetch_artifact  metalava  repohooks

And have you ever tried building androidx with the dev version of AGP(the one built from studio-main)?

I checked out androidx-main, is that the right one? There is no gradlew file under that directory.

Yes, aosp androidx-main is the repo. You'll want to use frameworks/support/gradlew thats the main repo all the work is done.

And have you ever tried building androidx with the dev version of AGP(the one built from studio-main)?

Yes we have a script for that https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:busytown/impl/build-studio-and-androidx.sh

namely you can set a number of variables to use the latest AGP (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:busytown/impl/build-studio-and-androidx.sh;l=92):

• GRADLE_PLUGIN_VERSION
• LINT_VERSION
• GRADLE_PLUGIN_REPO

and then run frameworks/support/gradlew

I believe this issue can be fixed by Jerome'CL ag/19955912. I got 4 snapshots running androidx to verify the fix.

1. the first run without the fix
2. the second run(config cached) without the fix
3. the first run with the fix
4. the second run(config cached) with the fix

From the snapshot of secondWithFix_xxx, if we do a search for MergeGeneratedProguardFilesCreationAction in the call tree, nothing would show up. However, if we do the same search for secondWithoutFix_xx, 3612ms is spent inside MergeGeneratedProguardFilesCreationAction.

The fix also reduce the time spent in non config cached run if we compare the same thing for firstWithoutFix_xxx and firstWithFix_xxx

Great bug Aurimas, very useful to get such bugs filed.

Verified again for the latest patch of ag/19955912. The snapshot of the config cached run and the screenshot of the search result of the MergeGeneratedProguardFilesCreationAction are attached. With the fix, the MergeGeneratedProguardFilesCreationAction would only take a 8 ms which is close to zero.