WIP: Try enabling configuration cache #195
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using the configuration cache can speed up builds by caching results of the configuration phase, which means that Gradle doesn't have to evaluate buildscripts multiple times.
An even bigger impact is that enabling this allows tasks in the same project to run in parallel, which is particularly helpful when working on the SDK: The steps to compile SQLite for
:static-sqlite-driver
are sped up a lot by running them in parallel (by default, we'd compile SQLite one ABI at a time).I've heard that the configuration cache doesn't work too well with some publishing plugins, so I've disabled it for the publishing CI. Apart from that, this should hopefully speed up our builds. We could cache the results of the configuration cche between CI runs too by setting a key to encrypt them with (it's not cached by default because the data may be sensitive). But I think the benefits of multi-threading alone could justify this and we don't necessarily need to worry about that.