I'm happy to mentor/guide anyone interested.

Same, I've never really grasped how all of that worked 😅

I see. But I don't really want to recommend using "-all" just for the few times when you need to debug your builds.

Thanks!

True, I'll add something about this.
I'm not trusting it 100% though and also I find breakpoints help best when you can also navigate the codebase you're debugging.

I haven't check but this dumps stuff like classpaths I think? That stuff adds up quite fast.

parallel cc did help (~200ms per project).
My CC size for the `help` task is ~400kB. For `build`, it's around 20MB, which sounds large but also in the reasonable range.

I didn't. It does help. Brings the time down to ~200ms per project or so.

Disabling cc completely indeed takes me to ~100ms per/projet. Not really sure what to do there. CC is useful in some cases but wasteful in others

Related: allenpike.com/2024/an-unre...

2026 is the year of fragment arguments!

Android plushies and a KMP talk about the pebble watch?
Can a conference get any better than this?

Super cool!

Yea. I had plans to add this to nmcp at some point. That's item #5820 on the todo list 😅

But the convention plugin is super important to optimize because every single invocation, including IDE sync will pay that price.
So how do you benchmark this without pulling specific tasks in the benchmarks I'm not sure. Probably you make several tries with different tasks.

Right. But as soon as you start optimizing for just one task, no need for `--dry-run`, you want the whole process to be fast.

If `compileKotlin` is taking 20s, no need to optimize the 2s of your convention plugin.

Agreed. Different ownership probably explain this.

Gradle did not want to add support for the new Central API so I guess GPG goes in the same bucket of "3rd party".

TBH I think it makes sense. Gradle can then focus on the build tool APIs.