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

Performance regression in 3.4.1

Open eygraber opened this issue 1 month ago • 1 comments

Gradle version 9.2.1

JDK version 23

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

(Optional) Android Gradle Plugin (AGP) version 8.13.1

Describe the bug I run a suite of static analysis checks on my project, and I noticed that clean runs have been taking longer than usual.

Doing profile builds with git bisect seem to show that updating DAGP from 3.3.0 to 3.4.1 is the culprit.

The issue only seems to surface when I run my full suite of static analysis checks; running buildHealth by itself doesn't seem to have an effect. My guess is that it's memory pressure related, but I didn't dig too deeply.

Using the task timing from Gradle scans I made this chart; the big offenders seem to be AbiAnalysisTask, FindKotlinMagicTask, and ComputeAdviceTask (total for 3.3.0 is 607.42s and for 3.4.1 is 665.13):

Task 3.3.0 3.4.1 Time Difference (%)
SynthesizeDependenciesTask 180.23 175.95 -2.38%
ComputeUsagesTask 84.62 96.59 14.14%
ExplodeJarTask 74.41 76.99 3.48%
FindKotlinMagicTask 16.31 55.68 241.39%
DiscoverClasspathDuplicationTask 59.27 51.35 -13.37%
AndroidScoreTask 40.93 45.44 11.02%
ComputeAdviceTask 12.23 27.42 124.24%
GraphViewTask 25.81 19.38 -24.91%
AbiAnalysisTask 4.58 16.15 252.87%
ClassListExploderTask 12.37 12.97 4.85%
SynthesizeProjectViewTask 11.10 12.45 12.25%
FilterAdviceTask 7.91 10.70 35.32%
AndroidCodeSourceExploderTask 9.24 10.57 14.40%
ArtifactsReportTask 13.55 8.61 -36.42%
ManifestComponentsExtractionTask 9.53 8.30 -12.91%
XmlSourceExploderTask 7.39 8.01 8.47%
FindServiceLoadersTask 6.76 7.12 5.26%
FindAndroidResTask 8.52 5.94 -30.25%
AssetSourceExploderTask 5.96 5.18 -13.05%
FindAndroidLinters 4.41 3.02 -31.42%
FindAndroidAssetProviders 5.05 2.72 -46.14%
FindNativeLibsTask 3.32 2.46 -25.90%
FindDeclaredProcsTask 2.45 1.23 -49.69%
FindDeclarationsTask 0.76 0.84 10.47%
GenerateBuildHealthTask 0.73 0.04 -94.00%
BuildHealthTask 0.01 0.00 -83.33%

I can share the Gradle scans privately (I have scans for 3.2.0, 3.3.0, 3.4.1, and 3.5.1)

eygraber avatar Nov 30 '25 08:11 eygraber

Thanks for the issue.

Build scans might be useful as a secondary resource,* but to really understand the source of a performance slowdown like this, I need CPU profiles, e.g. from JFR. See here for an example of how to use JFR to get CPU profiles.

You could either run it with buildHealth, or specifically run one of the tasks you've highlighted, which might provide somewhat easier-to-read results. If you do this, please ensure all runs are comparable. For example, use --rerun or --rerun-tasks (etc).

*Such as checking memory consumption, build flags, and ensuring general commensurability of the various runs.

autonomousapps avatar Nov 30 '25 22:11 autonomousapps

I had a thought, and I think it's plausible that it's this change in 3.4.0 that caused the regression:

[Fix]: Improve IP safety of GlobalDslService.

That involved some additional locking in the GlobalDslService class.

To confirm, you could use gradle-profiler to run benchmarks of your build with and without that commit reverted.

autonomousapps avatar Dec 08 '25 03:12 autonomousapps

I'll try to set some time aside to do that, thanks!

eygraber avatar Dec 08 '25 04:12 eygraber