build time increased after updating from plugin version 4.1.2 to 4.2.x

[vekonypeter]

Expected Behavior

the build takes the same (or less) amount of time after plugin version upgrade

Actual Behaviour

we have a pretty big multi-module project where build time increased significantly after updating the Gradle plugins to version 4.2.1 from 4.1.2. Our CI/CD build time went up from ~20 mins to ~50. Local builds also got slower, although not that drastically, but for example the simplest task also takes at least 30 secs (was < 1s before), because the configuration phase takes several seconds.

Steps To Reproduce

No response

Environment Information

Local:

• MacOS 12.7.1
• Gradle 8.4
• JVM 17.0.5 (Eclipse Adoptium 17.0.5+8)

CI/CD:

• ubuntu-2004:2023.07.1
• Gradle 8.4
• JVM openjdk-17-jre

Example Application

No response

Version

Plugin v4.2.1, Micronaut v4.2.4

[melix]

Without more information it will be difficult to tell what is going on. There can be multiple factors contributing to this. Note that we just releases 4.3.0 that you might also want to try.

Can you tell which tasks take time configuring? What tasks are you invoking? Any chance you can share build scans?

[vekonypeter]

@melix our current observation is that locally the simplest task (e.g. a clean) also takes several seconds instead of e.g. 1s, which is spend in the configuration phase. I have profiling only for now, for example:
before:

after:

But that's really just to demonstrate that something is going on there during configuration. On CI/CD, this config time is about 6 additional minutes before each bigger step using running gradle tasks (static code checks, tests, etc.), that adds up in the end.

regarding 4.3.0 - already tried it, but got the following error for multiplatform modules when I start using this version:

An exception occurred applying plugin request [id: 'org.jetbrains.kotlin.multiplatform']
> Failed to apply plugin 'org.jetbrains.kotlin.multiplatform'.
   > Gradle#projectsEvaluated(Action) on build '....' cannot be executed in the current context.

happens with any task I want to run

[melix]

Unfortunately the "old profile" is way too limited to debug anything. The error you are seeing with 4.3 is also unexpected, but it may hint at an issue with your build itself, which may trigger eager configuration of tasks when it shouldn't. I do not exclude a regression in our build plugins but since we're not seeing that in other projects, it's a bit puzzling...

[melix]

Could you maybe create a minimal reproducer which would mimic your build? It looks like you have a particular setup with Kotlin multiplatform, so it may be related.

[adamkobor]

@melix we're seeing errors in non-multiplatform (but multi-module) projects too on 4.3.0. the interesting part of the stacktrace could be this one probably:

Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin class 'io.micronaut.gradle.MicronautComponentPlugin'.
	at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:176)
	at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:153)
	at io.micronaut.gradle.MicronautMinimalLibraryPlugin.apply(MicronautMinimalLibraryPlugin.java:32)
	at io.micronaut.gradle.MicronautMinimalLibraryPlugin.apply(MicronautMinimalLibraryPlugin.java:27)
	at org.gradle.api.internal.plugins.ImperativeOnlyPluginTarget.applyImperative(ImperativeOnlyPluginTarget.java:43)
	at org.gradle.api.internal.plugins.RuleBasedPluginTarget.applyImperative(RuleBasedPluginTarget.java:51)
	at org.gradle.api.internal.plugins.DefaultPluginManager.addPlugin(DefaultPluginManager.java:190)
	at org.gradle.api.internal.plugins.DefaultPluginManager.access$100(DefaultPluginManager.java:54)

[melix]

This doesn't tell much unfortunately, except that the problem happens in MicronautComponentPlugin. Does it mean you're applying the Micronaut plugins on a multiplatform project? I don't think we have any tests for this. For both things (the configuration time issue and this error) a reproducer would really help.

[adamkobor]

This doesn't tell much unfortunately, except that the problem happens in MicronautComponentPlugin. Does it mean you're applying the Micronaut plugins on a multiplatform project? I don't think we have any tests for this. For both things (the configuration time issue and this error) a reproducer would really help.

my problem happens in a dead simple JVM multimodule project, it has nothing to do with multiplatform, and we've also seen the performance penalty between 4.1 and 4.2

[melix]

my problem happens in a dead simple JVM multimodule project, it has nothing to do with multiplatform, and we've also seen the performance penalty between 4.1 and 4.2

Then really, please, provide a minimal reproducer. I tried with a simple multiproject build generated by GCN and I cannot reproduce any configuration time issue, so I suspect it's the way you apply the plugins or configure your build which triggers eager configuration of tasks. see https://scans.gradle.com/s/ac7t4d7fg27ck/performance/build for example.

[rorueda]

I am experiencing the same issue in a multi-module java project with about 40 sub-modules. It started after upgrading micronaut from 4.1.2 to 4.2.4 (and gradle from 8.1.1 to 8.5). After some profiling I think gradle/gradle#25226 is causing it as can be seen by the flame graph below.

Anyway, I have no idea why it started now as it seems the gradle issue is present since 8.1.1 at least, or if there is any change that can be made to my configuration to fix this.

[rorueda]

I tested the gradle fix and indeed it improves a lot the configuration time, in my project from ~40s to ~6s.

I don't know if it is a configuration issue on my side, but it is still slow after the fix because getLibraryAliases().stream().map(micronautCatalog::findLibrary) in AutomaticDependency is being called ~600 times during configuration.

I also tested a modification to the plugin in which the micronaut catalog libraries are cached and the time was reduced to ~1s.

[melix]

I can confirm that the issue is in Gradle's version catalog APIs. I'm going to check if I can workaround the problem.

[melix]

Issue should be (mostly) fixed in Gradle plugin 4.3.2, released earlier today