Caching results of @InputFiles method, is it bad?


(Chris Doré) #1

I recently wrote a small test build based on questions posted by some other forum users.

In that example, I have the EmbeddedInputs.getDependencies method cache the results of the work in order to speed up subsequent calls (since Gradle calls the method many times, 5 I think).

My testing, with continuous mode as well, has not shown any issues so far. I’d like to know if this pattern should be considered a bad practice or if I’ve missed something.


Cache inputs resolved from main input file to speed up configure times
(Stefan Wolf) #2

Hi Chris,

It is perfectly valid to cache the result of an expensive calculation. Note that you could create a FileCollection with only one Callable (or a Closure) inside, the Callable memoizing its result.
This way, calling the getter does not cause evaluation of the Callable - only resolving the file collection itself does - and that would happen fewer times than the getter is called (currently twice for up-to-date checks I think). It still would make sense to cache the result of the Callable, so the expensive calculation is only done once.

The only problem which can arise is if the calculation happens to early and the build script changes the task property after it has been evaluated the first time. This is the reason why I would move the code into a FileCollection, so the actual calculation is done later.

We may provide some infrastructure for this common use case at a later point (something like a lockable Provider/FileCollection), but I cannot make any promises for now.

Cheers,
Stefan