ComputeUsagesTask taking 30+ minutes to execute when it used to take 30 seconds for the same project

[kyhule]

Build scan link
I have buildscans on company's internal instance if need info.

Plugin version
Seeing in 1.29.0 and 1.30.0

Gradle version
8.6

JDK version
17

(Optional) Kotlin and Kotlin Gradle Plugin (KGP) version
1.9.20

(Optional) Android Gradle Plugin (AGP) version
8.1.4

Describe the bug
When running projectHealth, ComputeUsagesTask increased from ~30s to ~40m after upgrading to version 1.29.0 on our main app module.

To Reproduce
Steps to reproduce the behavior:

1. ...

Expected behavior

Additional context

[autonomousapps]

Are you using the configuration cache?

[kyhule]

No, configuration cache was not enabled for either run. No, configuration cache was not enabled for either run.

[autonomousapps]

Can you try 1.30.0?

If you get the same results, I'd like to see CPU and memory profiles to investigate. The biggest change between 28 and 29 is using the new AGP APIs. 30 makes further improvements in this vein. If you're not already doing it, I would suggest disabling auto-apply behavior and instead manually applying DAGP to each module.

[kyhule]

I saw the same results using 1.30.0 which is where I first noticed it. I dropped back to 1.29.0 first and then 1.28.0 before the regression went away. I am relying on the auto apply; I'll try running without it. I am upgrading to AGP 8.2.2 right now so I'll see if that makes any difference. If none of that proves to help, I'll get cpu and memory usage on it.

[autonomousapps]

I wonder if memory usage went up and you're GC thrashing. Could you take a look in the performance tab of your build scans and see what's happening with your memory?

[kyhule]

I wonder if memory usage went up and you're GC thrashing. Could you take a look in the performance tab of your build scans and see what's happening with your memory?

Nope, doesn't seem to be a GC issue.

[kyhule]

I wonder if it is due to the fact that we have nonTransitiveRClass disabled (set to false). Did a heap dump and seeing a ton of instances of AndroidRes objects.

[autonomousapps]

I wonder if it is due to the fact that we have nonTransitiveRClass disabled (set to false). Did a heap dump and seeing a ton of instances of AndroidRes objects.

maybe. the plugin can't even give accurate advice relating to Android resources with that disabled.