# Introducing Configuration Caching

DevFeed: [Introducing Configuration Caching](<https://devfeed.tech/articles/introducing-configuration-caching-24650.md>)

Original publisher: [Read original article](<https://blog.gradle.org/introducing-configuration-caching>)

Author: Paul Merlin

Published: 2020-08-10T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [build performance](<https://devfeed.tech/topics/build-performance.md>), [Development](<https://devfeed.tech/topics/development.md>), [ide](<https://devfeed.tech/topics/ide.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [build-performance](<https://devfeed.tech/tags/build-performance.md>), [caching](<https://devfeed.tech/tags/caching.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [experimental](<https://devfeed.tech/tags/experimental.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [incremental](<https://devfeed.tech/tags/incremental.md>), [parallel](<https://devfeed.tech/tags/parallel.md>)

## AI overview

This article introduces Gradle's experimental configuration cache, which stores the result of the configuration phase for reuse in later builds. It can skip configuration when relevant build inputs are unchanged, increase parallel work, and cache dependency resolution, while requiring compatible build scripts and plugins.

## Source excerpt

This is the second installment in a series of blog posts about incremental development -- the part of the software development process where you make frequent small changes. We will be discussing upcoming Gradle build tool features that significantly improve feedback time around this use case. In the previous post, we introduced file system watching for Gradle 6.5. In Gradle 6.6 we are introducing an experimental feature called the configuration cache that significantly improves build performance by caching the result of the configuration phase and reusing this for subsequent builds. Using the configuration cache, Gradle can skip the configuration phase entirely when nothing that affects the build configuration, such as build scripts, has changed. On top of that, when reusing the configuration cache, more work is run in parallel by default and dependency resolution is cached. The isolation of the configuration and execution phases, and the isolation of tasks, make these optimizations possible. Note that configuration caching is different from the build cache, which caches outputs produced by the build. The configuration cache captures only the state of the configuration phase. It's also separate from IDE sync and import processes that do not currently benefit from configuration caching. In order to cache the configuration result, Gradle applies some strong requirements that plugins and build scripts need to follow. Many plugins, including some core Gradle plugins, do not meet these requirements yet. Moreover, support for configuration cache in some Gradle features is not yet implemented. Therefore, your build and the plugins you depend on will likely require changes to fulfil the requirements. Gradle will report problems found with your build logic to assist you in making your build work with the configuration cache. The configuration cache is currently highly experimental and not enabled by default. We release it early in order to collect feedback from the community