IssueTracker

We tried to add @DoNotCacheByDefault but got performance regression from some of our benchmarks so we revert the change in I031cf4a63f8c45538cc5247d29e2d30d03cfe21e

Hi, we are interested in the details of the performance regression caused by disabling the cache in the task. Are those regressions on the MergesSourceSetFolders tasks?

We were considering dropping our workaround and we measured the duration of the task when the outcome is executed or from-cache and we want to share the results:

We defined four scenarios, including different files in the assets folder. The agents are GHA runners executing 20 incremental builds per variant:

Results small scenario, task :core:network:packageDemoDebugAssets

Results medium scenario, task :core:network:packageDemoDebugAssets

Results large scenario, task :core:network:packageDemoDebugAssets

Results extra-large scenario, task :core:network:packageDemoDebugAssets

Can you give us please, more details on the potential performance regression?

Thanks

We attempted to change the cacheability of MergeSourceSetFolders together with some other tasks:

• Original commit: https://android.googlesource.com/platform/tools/base/+/2e24606cb1ebb77c34e0c7200f06903be2b1db02
• Revert commit: https://android.googlesource.com/platform/tools/base/+/ff2ce500c30e00b6065ea22777b6e41500ae33a0

Maybe we should consider the cacheability of MergeSourceSetFolders in isolation.

Did you perform your experiments with a local cache or remote cache? (I guess the results will be more convincing if it is a local cache.)

Hi, the experiments were using only local cache

Cool, thanks a lot for your detailed results. Looks like we should disable caching for this task based on your experiment.

(Btw, experiments like what you did are super useful to help us decide which tasks should have caching or not. I think there is a plan in Gradle to take care of this for users, but before we get there, we'll need to fine-tune one task at a time then.)

Hi Bingran, I can take over this bug, please let me know if you have any concerns with disabling caching for this task.

Our builds were having thousands of remote hits for completely empty MergeSourceSetFolders tasks. It generated significant traffic to our build cache and we are going to disable it with the cache-fix plugin. Using local cache helps, but the best fix seems to be disabling caching for these tasks entirely.

Thanks for the extra info.

We've disabled caching for the MergeSourceSetFolders task in AGP 8.4.0-alpha02+: https://android.googlesource.com/platform/tools/base/+/dcf719b0a81eda745a594a3f937d6dee710156c9 (note: this link is currently not visible, but I believe it will be after some time).

After the above change, we've noticed some performance changes on our benchmarks for the cleanBuild scenario with build cache enabled (see attached screenshot):

• On Base100 and SantaTrackerKotlin: MergeSourceSetFolders task time increased by 50-250ms.
• On SantaTracker: MergeSourceSetFolders task time decreased by 170ms.

That means it really depends on the specific project: Some projects will benefit from this task being cacheable, while others do not.

Given the differences on our benchmarks are less than 1s, whereas the differences in the largest project in comment #3 are in seconds, I guess we will keep the above change.

However, if other users think this task should be cacheable, please give us your numbers and we will re-consider this decision again. Thank you!

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Jellyfish | 2023.3.1 Canary 1
• Android Gradle Plugin 8.4.0-alpha01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!