dependency-analysis-gradle-plugin icon indicating copy to clipboard operation
dependency-analysis-gradle-plugin copied to clipboard

Published 20 hours ago • verified publisher icon autonomousapps

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

Open kyhule opened this issue 1 year ago • 8 comments
trafficstars

Build scan link I have buildscans on company's internal instance if need info. CleanShot 2024-02-20 at 12 55 05@2x CleanShot 2024-02-20 at 12 55 27@2x

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

kyhule avatar Feb 20 '24 18:02 kyhule

Are you using the configuration cache?

autonomousapps avatar Feb 22 '24 20:02 autonomousapps

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

kyhule avatar Feb 23 '24 01:02 kyhule

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.

autonomousapps avatar Feb 24 '24 05:02 autonomousapps

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.

kyhule avatar Feb 24 '24 12:02 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?

autonomousapps avatar Feb 24 '24 17:02 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?

Nope, doesn't seem to be a GC issue. CleanShot 2024-02-24 at 15 16 32@2x

kyhule avatar Feb 24 '24 20:02 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. CleanShot 2024-02-24 at 15 26 19@2x

kyhule avatar Feb 24 '24 20:02 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. CleanShot 2024-02-24 at 15 26 19@2x

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

autonomousapps avatar Feb 24 '24 22:02 autonomousapps