Hello folks. I was making some changes to my gradle setup, and I want to understand if what I am doing is going to be a net benefit or a net negative in terms of speed. Is there a way in which I can at least to a decent extend do a setup where I can see how a clean build works before those changes, then checkout the git branch with my changes, and run the same task there and try to compare the two? I am aware that

--scan

exists which is probably where I should go to start comparing, but how can I get a true clean build, so that the two builds I will be comparing are actually comparable in a fair way? What I tried so far is: • Checkout the branch. • Sync project. • Run

./gradlew clean

• Run

./gradlew buildDebug --scan

Did this to both of my branches, and I thought the build looked comparable, but then I did it again with another branch and the build then was not comparable at all. The first two builds were 4 minutes, and 3.30 minutes respectively. The third run was 1 minute. So I feel like I am definitely missing something. Any tips here?

I guess your 3rd build reused build cache entries, which are of course not affected by

clean

or it would be senseless. 🙂

Yeah I actually thought the clean would clean those too. Let me look into that, thanks for the pointer 😊

You can use a dedicated

GRADLE_USER_HOME

in addition for each run for example.

I would use

--rerun-tasks --no-build-cache --no-configuration-cache

to ensure you're doing the same exact clean build

💡! Am I correct that if I add these flags I wouldn't even need to run a clean before, or would that still be useful for some other reason? Also, do you think I should do a

./gradlew --stop

before each run, or would that be useless? I am not doing any super high quality comparisons or building dashboards here btw, just want to get a ballpark of approx how much what I am doing helps or not.

If you use

--rerun-tasks

,

--no-build-cache

is pointless. Also doing

clean

is kind of pointless, yes. Which flags to use or whether to clean or use a clean gradle user home or whether to stop the daemon all majorly depends on what exactly you want to compare. For example, if the optimizations you do are really in the work the tasks are actually doing,

--rerun-tasks

should be fine, stopping the daemon in-between the runs ensures the daemon is started on each run and so eleminates the difference from starting the daemon, but you could also simply add

--no-daemon

which nowadays usually mean to always start a one-off daemon that is shut down after the build execution. If the optimizations for example are for more reliably being up-to-date or for having tasks cacheable, then those options are more counter productive for the comparison, ...

All very valid points here Björn. It should help for me to be a bit more concrete. I have been doing some changes to our project where I have been trying to do two things: • We have one big module with all of our GraphQL models, which as far as the scans tell me is a bottleneck. That needs to finish before a lot of other dependant modules get a chance to start • We have a lot of modules which are android libraries, but if you look inside they could very well just be simple jvm libraries instead I wanted to do a simple comparison of a clean build before me fixing those, and after. You are absolutely right that in a typical work day you don't really run clean builds that often, but I leaned into this as it felt like the easiest metric to look into and get more or less reliable info out of, as anything more involved would be outside of my skill set. For some more context, we are a 2 people team, we don't have any build engineers, build metrics we track (besides just looking at the CI times) or any Gradle experts in the company as a whole. So I am just doing this as an opportunity both to learn more about Gradle, but also to improve my and my colleague's life a tiny bit 😊

👋 Björn, my understanding is that if

--rerun-tasks

by itself Gradle could still fetch the build cache but would still ignore any hits? That would add noise to comparisons that seek to eliminate sources of variance between builds.

I would expect that it also does not look for the cache if it is not going to reuse it. If it does, that would IMHO qualify for a bug report. Gradle usually is pretty awesome in avoiding unnecessary work which is one of the biggest advantages over for example Maven. But I don't know it for sure.

I'll check it out and report back. Should be able to see in a scan if it spends time checking cache or not under rerun.

First one took 57 seconds total, while the second one took 1m 34s total. That’s like a 50% increase, that’s pretty huge no?

A huge part of that difference is configuration cache, however another run shows that execution time can also continue to decrease. While 100% of tasks are rerun, 203 units are requested from build cache.

Oh the “no-cache” one took 28seconds configuring vs 3sec for the other one, I see that now

Seems like transform execution is what continually improves even without build and configuration cache.