Should 'Task graph calculation' and 'Configuration caching' take so long? I'm making minor changes to source files and re-running the same task, and it's really disruptive that Gradle is dragging its feet for 2 minutes every build. The build scan gives zero useful information Can I do anything to investigate?

I would think "it depends" calculating my configuration cache is easily the slowest part of my build, it's like 45s. which is why the configuration cache is useful, so you don't have to recalculate it every time. Should it? I don't know, I have no idea what gradle is doing that it's caching. We don't know what task you're running, any configuration properties, or what you're modifying. So to answer this further is kind of hard. Possible you can get more information by increasing logging verbosity to --debug... . Sorry not being very helpful 😉

I think we're on the same wavelength Caleb, I just needed to vent more than anything, so vague advice helps 😁

I'm all about promoting venting! I have this special attachment valve to my neck that lets me do that. It's called my mouth and it's constantly running...

It's a closed source project, otherwise I would share the source & scan. It's using Kotlin Multiplatform 1.9.32, and Gradle 8.7, so it should be fast. Something unusual about it is that there are many composite builds.

I’m making minor changes to source files and re-running the same task

If you are only doing source file changes, the next build should be a configuration cache hit. Does the console give you any indication why it isn’t a CC hit?

yeah, that's what I thought too @wolfs I've run with

--debug

and I can see thousands of lines about fingerprinting files, and it seems slow

You don’t need debug for that. You can check the CC report. And there will be some printout at the beginning, like https://ge.gradle.org/s/r6thvbkjtqx7c/console-log?page=1#L0

the only message I can see about configuration cache is this, but that file hasn't been changed in a long time

Calculating task graph as configuration cache cannot be reused because the file system entry 'modules/interop/build/tmp/downloadSource/Images/icon.jpg' has been removed.

Hmm… For some reason that jpg ends up as an input of the build configuration.

And now I see this message

Calculating task graph as configuration cache cannot be reused because the file system entry '.gradle/configuration-cache/cfwillt1lnakn3lk0glzqb1u/projectfingerprint2384331854675562243.tmp' has been removed.

Hmm… That is all very strange. Is the

.gradle

directory a configuration input as well?

I guess 🤷 I don't know, Gradle doesn't really explain

Hmm... I'm not sure that reading .git is definitively inappropriate at configuration time. For example I suspect it's my version plugin that reads .git at configuration time. However, not all configuration cache invalidations appear to be equal. Whatever is reading my git directory repopulating that part of the cache appears to be fast. Now recursively reading all of the git directory? Shouldn't be happening in my case... I read a security bug apparently there's a version of jgit in Gradle itself, which tells me it does something with Git. Also, to be honest I'm not even sure what people use the idea plugin for anymore... Seems to work pretty well without it most of the time. Also I just had another idea. Have you tried running strace against your build? That'll tell you what files are being read. It will tell you all the files that are being read, So it'll take a while to use that and figure out what the problem is most likely

good point, maybe some .git files are valid inputs. But reading the entire .git dir is probably not correct!

Yes I would agree with that

A YouTrack issue is a good idea!

did you create (or find) that youtrack so I can thumb it up?

@Caleb Cushing done https://youtrack.jetbrains.com/issue/IDEA-351187/Exclude-generated-Kotlin-DSL-accessors-from-project-wide-search