gradle CONFIGURATION phase from 3sec to 1min+ after switching to 3.16.1

[Shohou]

Describe the bug

After switching from version 3.13.3 to 3.17.3 I noticed that gradle configuration phase takes more than a minute to complete. On 3.13.3 it was very quick, about 3 seconds or even less. I checked different versions:
3.13.3 -> ok
3.14.4 -> ok
3.15.2 -> ok
3.16.4 -> not ok
3.16.1 -> not ok
3.17.3 -> not ok

Here is a project which demonstrates the problem - https://github.com/Shohou/gradle_quarkus_3.16
run ./gradlew build and see how long it takes for CONFIGURATION phase to complete. First time it might be even longer because of libraries download, but then run it again and it still takes over 1 minute.

You can modify gradle.properties and change there quarkusPluginVersion, quarkusPlatformVersion to 3.15.2 and see how fast CONFIGURATION phase passes, although whole project takes about 3 minutes to build without a single java file, but with some libraries.

Expected behavior

I expect CONFIGURATOIN to take about 3 seconds, slightly more with libraries download

Actual behavior

It takes 1 minute+

How to Reproduce?

Download project from here - https://github.com/Shohou/gradle_quarkus_3.16
run ./gradlew build

Output of uname -a or ver

No response

Output of java -version

openjdk 21.0.4 2024-07-16 LTS

Quarkus version or git rev

3.16.1+

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 8.9, also tried with 8.11.1

Additional information

No response

[quarkus-bot]

/cc @glefloch, @quarkusio/devtools, @radcortez (config)

[aloubyansky]

@cdsap you may be interested in this one

[cdsap]

The configuration cache changes require eager resolution of the dependencies causing this duration.
With the reproducer included below we can observe the issue described:

• First build (downloading dependencies): https://ge.solutions-team.gradle.com/s/2zxvsrxyk7m7s/performance/configuration
• Second build (reusing dependencies): https://ge.solutions-team.gradle.com/s/5fwa5ouczsvr4/performance/configuration

I assume my times are faster because I'm using a M1.

Investigating

[ryandens]

👋 Just wanted to chime in here that a project I'm working on (closed source) is experiencing this behavior as well; I haven't had the time to dig in/make a reproducer like the one linked here. Our project (larger than the one linked) went from taking 6 seconds to calculate the task graph on a full cached build (no tasks executed) to 58 seconds for a fully cached build. This is without the configuration cache enabled, on an M2 Pro with 32GB of ram. I had skimmed the release notes and hadn't seen the news about configuration cache compatibility for QuarkusBuild tasks (#42496).

I tried enabling the configuration cache on the reproducer project linked to this issue, but the entry is discarded each time due to probelms with how the quarkus plugin configures gradle's test task.

[cdsap]

The issue is related to the request of the deployment configuration with getIncoming().getFiles(). This is required to include the potential alterations of the resolved dependencies with components like Conditional Dependencies.
The durations you're mentioning @ryandens are not acceptable, I'm evaluating how we could keep the conditional logic from the Model Task perspective without forcing the unnecessary resolution.

Regarding the configuration cache compatibility, a build invocation requires QuarkusTest task that at this moment is not compatible with conf cache.

[ryandens]

Agreed— I'm delaying minor version upgrades at the moment, but depending on which bugs/security issues come in, I will eventually have to take the productivity hit. If there's any help/more info I can provide, please let me know!

[cdsap]

Hi, we have merged a partial fix that mitigates the configuration duration by preventing the recalculation of dependencies if they have already been computed. While the duration is still not comparable to 3.15.x, we have achieved around a 40% reduction in the current reproducer. I am continuing to investigate the root cause, as the issue stems from multiple dependency calculations during configuration time.