Enable configuration cache #195
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
simolus3
force-pushed
the
configuration-cache
branch
from
938414e to
ab72541
Compare
simolus3
changed the title
simolus3
force-pushed
the
configuration-cache
branch
from
5298f7d to
658b5a3
Compare
stevensJourney
approved these changes
Jul 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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-driverare 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.