This message was deleted.

I don't know numbers, but 20% time increase for caching overhead seems a bit too high. But I really don't know. Maybe comparing build scans if possible would show whether it is really the caching that needs that additional time. Regarding enabling by default, if tasks are poorly written / used, that is do not declare the inputs and outputs properly or do have tasks with overlapping outputs and so on, the build cache could cause wrong build results and / or flaky builds. So having it disabled by default is the safer choice.

The main reason why the flag isn’t enabled by default is the possible overhead. Though for incremental builds it shouldn’t be 20% (what is the absolute number?), it should probably more be in the 1-2% area since only the executed tasks will be stored in the build cache again.

~7 seconds First screen:

org.gradle.caching=false

Second screen:

org.gradle.caching=true

Scenario:

incremental_app {
  tasks = [":app:assembleDebug"]
  apply-abi-change-to = "PATH_TO_FILE"
  apply-non-abi-change-to = "PATH_TO_FILE"
}

What kind of build is this and what is the incremental change? 20 seconds for an incremental change seems pretty slow.

There are run 6 warm up builds + 10 measured builds. All of them with one task:

app:assembleDebug

and abi change to random file + non abi change to other random file.

Looking at a build scan to figure out which tasks have the biggest cache overhead would be a good idea I suppose. There also have been some fixes in later versions of Android to not cache things which have a larger cache overhead.

There is a really nice plugin to disable cacheability of tasks that usually introduce negative savings for Android builds. You could also try to rerun your experiments applying it to see if there is any significant improvement.

I run two scans (with build caching enabled): • clean + app:assembleDebug • assembleDebug The second time, 137 tasks were run again even if nothing change in the project 🤔. Also one of them was really long, ~27seconds