How does Gradle's configuration cache improve build performance?

Normally, every Gradle invocation re-runs the configuration phase — executing every project's build script to rebuild the task graph — even if nothing about that structure has changed since the last build. The configuration cache serializes the result of that phase (the fully resolved task graph and its inputs) to disk, so a later build with an unchanged configuration can skip straight to the execution phase entirely.

# gradle.properties
org.gradle.configuration-cache=true

When enabled, the first build after a configuration-relevant change still pays the full configuration cost and stores a new cache entry; every subsequent build that doesn't touch build scripts, settings.gradle, or their inputs reuses that stored graph directly. This can meaningfully cut wall-clock time on large multi-module builds, since script evaluation itself — not just task execution — is often a nontrivial chunk of total build time on big projects. Not all plugins or build script patterns are compatible yet, so a build's configuration cache "report" flags anything that prevents caching, like a task that reads a project property inline during its configuration.