Performance regression in 3.4.1

[eygraber]

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)

[autonomousapps]

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]

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.

[eygraber]

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

[eygraber]

Reverting that commit from the v3.5.1 tag solves the performance issue. Reverting it from HEAD (04a70b0) causes a smaller performance issue. I'll do a bisect there to find the offending commit.

[eygraber]

Actually it looks like it was #1602 (the profiler was acting weird yesterday, so I re-ran my tests).

Going to benchmark with the opt-out and upload the benchmarks here when done.

[eygraber]

Benchmark from f20e9e0

warm-up build #1,398115.45
warm-up build #2,167001.92
measured build #1,154580.34
measured build #2,163096.85
measured build #3,151050.04

Benchmark from b353f4e

warm-up build #1,416787.98
warm-up build #2,195316.08
measured build #1,189417.59
measured build #2,177212.47
measured build #3,179807.69

I tried using the opt-out (-Pdependency.analysis.check-binary-compat=false) on 3.5.1, but it was inconsistent, sometimes mirroring the performance of f20e9e0 and sometimes b353f4e