This message was deleted.

My understanding is that the main reason to have a rule not cacheable is if you cannot isolate its state. That's why rules you write without class –

dependencies.components.all { allVariant { ... } }

– are never cacheable. The "cache" here is the metadata cache that is also used for the metadata downloaded from repositories. So the cache is always involved anyway when dependency resolution is performed. When you do not cache a rule, it always runs during resolution after the original metadata was read from the cache. If you make it cacheable, the result is stored in the cache and the resolution can read it from there directly (as if it were the original metadata). If it is worth depends on the size of the dependency graph(s) I think. And on how many of the nodes your rules operate. E.g. if you have many

all

rules that touch every single node in the graph, and your graph has 10thousands of nodes, you might see the impact. For reasonably sized builds and rules that don't do any heavy computation, it's probably not important to make them cacheable. And with the configuration cache, there is now another layer of caching, which probably also prevents not-cached rules to run on every build execution. I don't think overhead is something to worry about here.

Thx for your thoughts