Performance regression in 3.4.1
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)
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.
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.
I'll try to set some time aside to do that, thanks!