This message was deleted.

Can you share a build scan, or some more information about what types of tasks produce the negative savings?

I think

doNotCacheIf

fixes this issue, but at the cost of increasing clean build times - i'll check if it makes sense to do that in our project. the tasks taking most of amount of time packing are: 1. DexArchiveBuilderTask 2. TransformClassesWithAsmTask 3. KotlinCompile 4. KaptGenerateStubsTask total time spent in packing ranges around 10s to 18s

every task will take longer to execute when the build cache is enabled. it always adds some time to pack the entry. you will save more time in the long run, however when the task is pulled from the cache.

that makes sense, but this is quite a caveat since on machines like M1, build cache adds significant (10-20%) overhead as incremental (or any) builds on M1 are pretty fast

how did you calculate this value? what is the value like for non m1 builds?

the time taken by packing is mentioned in the Build cache section in the scans so if my incremental build on M1 takes 100 secs without Build cache, it takes 115 secs with Build cache (15 secs spent in packing) 115/100 = 15% overhead the overhead is lower in case of non-m1, because incremental builds take around 200 secs without Build cache 215/200 = 7.5% overhead

it seems to me that the overhead is exactly the same in both examples you had - 15 seconds. the m1 is a faster CPU which speeds up execution times of tasks but does not speed up disk bounds tasks or i/o heavy operations like caching.

got your point, thanks!