The first question I want to ask is what exactly is covered under the “model configuration” category? Do dependency resolution and network activity also fall under this?
The second question is about what to look at here.
We tried profiling using Gradle Profiler + async profiler.
But in a dry-run assemble task, the plugins that we’re using, which were executed under our convention plugins, only took less than 10% of the total build time.
What exactly do we need to look for? Is there a better way to find the problem here?
Clicking the question mark form your screenshot tells:
Model configuration
The time taken to evaluate settings and configure the projects participating in the build.
So I’d say that if the “dependency resolution and network activity” is done at configuration time (which usually is a bad idea anyway), then it would be part of that figure.
Below that screenshot you also see where exactly this time is spent to maybe find a potential culprit.
I assume we got other scripts as child item of root build.gradle.kts because we’re using rootProject.evaluationDependsOnChildren(), that’s one thing.
The other thing, inside analytics/build.gradle.kts the plugins only took about half of the total duration,
Does that mean the half is part of Script Compilation?
I see. In that case, based on the Dependency Resolution tab on the report, we can say that it’s included.
I would say the opposite.
Your screenshot shows that during configuration only 7 milliseconds are spent for dependency resolution and the 2m 2.252s shown are only done at execution phase.
Yes, but looking at this is also confusing. We got this report:
I’d say the culprit is not displayed in the screenshot.
None of the lines shows more than 2 spent seconds.
I assume we got other scripts as child item of root build.gradle.kts because we’re using rootProject.evaluationDependsOnChildren() , that’s one thing.
I have no idea, could be that this is the case.
But actually needing that call is anyway a code smell.
It usually suggests that you do bad-practice cross-project access, getting information from subproject models which is almost as bad as doing cross-project configuration.
So if this call is really necessary in your build it sounds like there is more to fix there.
The other thing, inside analytics/build.gradle.kts the plugins only took about half of the total duration,
Does that mean the half is part of Script Compilation?
Iirc you see the time needed for script compilation separately.
If the plugins spend half of the time and script compilation is not the rest, I’d guess the rest is execution of that script.
We have 1300+ modules though, maybe it’s just slow because we have so many modules?
I have no idea, maybe?
Maybe configure-on-demand will be something that helps once your build becomes compatible with it if it is really just the sheer amount.
I never used it myself, but I guess your evaluationDependsOnChildren() will disable it maybe.
