Cache heuristics about gradle

[pioterj]

Rather than making it configurable we could make it intelligent so that the system knows whether it's better to execute a task or get the result from the cache based on historical data.

[pioterj]

Such mechanism could be later reused for distributed builds to decide whether it's worth to move execution of a task to a different machine or just execute it locally.

[big-guy]

At the other end, instead of putting lots of smarts into Gradle, we could make it another diagnostic we produce. We're going to eventually be including metadata about where a particular artifact came from and providing more data for build scans. If we provided some or all of these things:

• time taken to retrieve cached output
• time taken to unpack output
• time taken to create the output originally
• time taken to execute the cached task (we already have this)

We could do a really simple diagnostic. If the time taken to execute the cached task is greater than the time taken to create the output originally and that time is greater than some threshold (10s), the build scan can say:

• If the unpacking is the slow part, disable the cache for task XYZ because it takes too long to unpack.
• If the retrieval is the slow part, speed up the connection to the distributed cache or disable caching for task XYZ.

If we had the task execution plan, we could even replay the build with the original, non-cached times. If the build would have finished sooner, we can suggest disabling the cache or speeding up the connection to the cache or speeding up the local disk (depending on what we can guess from the data).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.