The Unity Accelerator cache server supports the following types of caching. Each type has different characteristics that determine what it caches, its determinism, and what performance benefits it provides:
When you import an asset, Unity produces artifacts such as serialized data, metadata, Asset Database entries, and dependency information. You can enable import result caching in your project to store the artifacts for later reuse. Unity skips the full import on subsequent imports of an asset and downloads the complete result from the cache server, which provides faster import results.
Because imports support dynamic dependencies, Unity might discover new dependencies during the import process. Unity resolves a cache hit in two steps. It collects import result candidates for the asset, and then matches the candidate to use. If there’s a match, Unity downloads the cached artifacts.
However, import result caching might have non-deterministic results because of factors such as:
AssetPostprocessor code that modifies the result of the import in a non-deterministic way.Enable the Import Result Caching setting in the Project Settings window to enable import result caching. This setting is disabled by default in new projects after Unity 6.5.
You can also use the -cacheServerEnableImportResultCaching argument when launching Unity through a command line interface, or the Hub.
Shader variant compilation caching stores compiled shader code for specific platform and keyword combinations. Unity compiles shaders on demand, and compiles all variants of a shader during a Player build. Cached shader compilation output can be shared with other developers, or reused in future Player builds.
Shader compilation can be time-consuming, especially for complex shaders and large projects with many variants. In typical large projects, shader variant compilation represents a significant amount of the total processing time. In particular, a large proportion of Player build time is spent on shader compilation because this is the point where Unity compiles all shader variants.
Shader caching is enabled if you have Unity AcceleratorThe Unity Accelerator is an external tool that provides an asset cache that keeps copies of a team’s imported assets. The goal of the Accelerator is to speed up teamwork and reduce iteration time by coordinating asset sharing so that you don’t need to reimport portions of your project. More info
See in Glossary configured, and you can’t disable this behavior in the Unity Editor. However, you can disable it via command line arguments for advanced use cases.
Shader compilation caching is low risk, because it’s a closed system, where Unity tracks dependencies and isn’t affected by script code.
Texture compression caching stores compressed texture data for platform-specific texture formatsA file format for handling textures during real-time rendering by 3D graphics hardware, such as a graphics card or mobile device. More info
See in Glossary. When Unity imports a texture and compresses it to formats like DXT, BC7, ETC, or ASTC, it also caches the compressed data. Unity can then download the compressed data instead of recompressing on subsequent imports of the same texture. The compression stage is a step of the texture import process, and even if import result caching is disabled, Unity might reuse the previously cached texture compression3D Graphics hardware requires Textures to be compressed in specialized formats which are optimized for fast Texture sampling. More info
See in Glossary output.
Texture compression has an impact on performance, especially for high-quality settings and large textures, and in large projects with a large number of textures, texture compression can represent a significant proportion of total import time. Caching compressed textures can therefore reduce import times.
Texture compression caching is enabled if you have Unity Accelerator configured, and you can’t disable this behavior in the Unity Editor UI. However, you can disable it via command line arguments for advanced use cases.
Caching substitutes a previously computed result, which is only meaningful if the substituted value matches what the computation produces on any machine.
Some computations aren’t bit identical, even if the inputs remain the same. This is known as benign non-determinism. For example, ordering differences during parallel processes, or numeric drift can cause benign non-deterministic results, where the result is correct but not identical.
Using a cache server means that whatever result is the first to get written to the cache gets reused across the team, and therefore there’s no canonical output when debugging.
When benign non-determinism happens, it can be difficult to detect missing inputs because running the computation again always produces differing bits.
Another source of non-determinism is when a computation depends on something not declared as an input. The cache key doesn’t capture the true inputs and is non-hermetic.
A cached result reflects whatever value the undeclared input had when the result was produced. Everyone who then uses the cache server receives the non-hermetic computation. A cache hit can then return a result that was produced for a different Editor version, machine, or platform. A hit still looks successful, but the data is only valid in a different scenario.
Once a bad result is written under a key, every consumer that subsequently looks up that key receives it.
A cache hit returns stored output only, and is reliable if the computation only has a return value. If the computation writes files, sends network requests, emits logs, or changes other states, then the cache hit skips that work.
Any code that depends on that work silently breaks on a cache hit. For example, a later step expecting a file to be written finds nothing, or tooling watching for a log line stops seeing it. The return value is correct but everything else is missing.