Oh I hate Gradle. They told us modularizing would ...

# gradle

[Paul Woitaschek]

Oh I hate Gradle. They told us modularizing would speed up the build. Now my Gradle sync takes 2 minutes each time 😿

[artem_zin]

lol, welcome to the club

the thing is, Gradle never told that, those were people in the community

[hallvard]

I take it you do not come to gradle from sbt?

[gildor]

Just curious, how many modules do you have?

[madisp]

Gradle sync with 100+ modules should still be like a few seconds at most?

[artem_zin]

really depends, configuration phase is very problematic

- it’s not cached
- it’s serial (anything that blocks it, like file i/o blocks the entire thing)

[artem_zin]

for us it’s 20-60 seconds on macbooks (2018 i9 to 2016 i7), we don’t do file io and in general maintain our build.gradles in good shape

[dsvoronin]

while configuration phase is kinda fast for us (~200 modules, ~20 inhouse plugins affecting configuration phase, android project) and about 10-30 sec on warmed up daemon
AS sync on other side could be 1-2 min easily (library modules with ignored debug type, skip sources generation in IDE)

[gildor]

10-30 sec only for configuration?

[dsvoronin]

yep, kotlin android extension still forces deps resolution in config time

[gildor]

Yeah, this is a big problem

[dsvoronin]

and i think we know 1-2 more places for improvements, that specific to our shit coded scripts

[dsvoronin]

+ kts problems

[gildor]

Problem with android extensions should be fixed in 1.3.20

[dsvoronin]

yep, subscribed to half of jb youtrack 😄

[dsvoronin]

maybe we should create somthing like community driven “known issues” repo, with this secret knowledge about current gradle issues?

[orangy]

Why a different repo? It’s OSS, you can send PRs right to the docs!

[gildor]

Isn’t issue tracker is not enough?

[dsvoronin]

it’s not about issues only, but also for workarounds and hints

[gildor]

Problem that workarounds are not available often

[gildor]

like in case of android extension issue

[dsvoronin]

i don’t know what the right place for “don’t upgrade to 4.10 gradle if you have android project and use kts”

[dsvoronin]

yep, extensions will be like: expect some performance impact if you use it, around Xs. until KT-XXX will be fixed

[dsvoronin]

but you should upgrade to 1.3.20 then, and it forces you to upgrade gradle to 5.0x if you use kts, because it has some connection, but you couldnt if you on android, until agp support 5.0 gradle

[dsvoronin]

you could though, but kts in buildsrc and kotlin version in project has some hardly debuggable effects on each other, and there should be workarounds

[dsvoronin]

@artem_zin we need that emoji (open eyed laugh crying) here

[gildor]

Isn’t it problem of any pre-release software?

[gildor]

especially combination of multiple pre-release software

[dsvoronin]

it is stable now afaik )

[gildor]

4.10 yes, but not Kotlin DSL

[dsvoronin]

kotlin dsl is stable !

[gildor]

and afaik 4.x is not supported anymore

[dsvoronin]

https://github.com/gradle/kotlin-dsl/releases/tag/v1.0.2
but it’s part of unstable 5.0 gradle

[gildor]

Yes, and not available without Gradle 5.0

[gildor]

which is not released

[gildor]

But another problem that Android Gradle Plugin is highly coupled with Gradle

[dsvoronin]

ok, this particular problem sure is a my own headache

[gildor]

I mean, I feel your pain, had such cases myself, just better to expect it if you want to be on cutting edge 🙈

[Paul Woitaschek]

Problem with android extensions should be fixed in 1.3.20

[Paul Woitaschek]

Do you have a youtrack link?

[Andrey Uskov [JB]]

@Paul Woitaschek, could you please provide a steps to reproduce your issue? I'll try to take a look. BTW we have improved import process (KT-27832). The speedup is up to several times depending on project structure.

[gildor]

https://youtrack.jetbrains.com/issue/KT-26065

[dsvoronin]

@Andrey Uskov [JB] is there a target version for the fix? youtrack doesn’t have one

[Andrey Uskov [JB]]

@gildor, I'd like to see ab initio problem in order to make sure that KT-26065 is the only reason of slow import in the case.

[gildor]

What is "import" in terms of Gradle?

[gildor]

This is issue that cause visible overhead on each build because happening on configuration time, so adds overhead to every Gradle invocation

[Andrey Uskov [JB]]

@dsvoronin, it should be available in 1.3.20

[gildor]

You can check how many time of your configuration time you can save if you check your build scan dependency resolution time

[gildor]

It should be 0 for warm daemon without dendency changes

[Andrey Uskov [JB]]

@gildor, as far as I understand, this issue is not the only reason of slow sync process in Idea/AS. For example some slowdown was observed due to IDEA-200434 - impact on configuration phase, KT-26065 - overhead in Idea during dependency resolution. May be in the case we have any other issue.

[Andrey Uskov [JB]]

BTW the issue IDEA-200434 may affect performance of configuration phase because if you have a new gradle.init the configuration phase works longer.
Upd.: I've tested the case with Robot-Scouter, it looks like the fix of IDEA-200434 matters (sync duration: 32s at my PC before fix and 16s after fix).

[gildor]

this issue is not the only reason of slow sync process in Idea/AS

@Andrey Uskov [JB] Of course, and I never tell that.
This issue not about sync in general, but about “configuration phase” of gradle, which affects all gradle invocations and every build, not only sync.
Sync of project is completely different story