There is a new version available for two cache steps: Cache:Push and Cache:Pull and the upgrade to 2.0.0 (or above) will come with significant speed improvements!
All you need to do is click on the orange dots to upgrade the steps (in your Workflow) to the latest versions!
Simpler caching methods
The files and folder structures that are produced at the end of certain processes are called cache. They conserve a certain state, for example some information belonging to a file or a bunch of compiled code. This allows reuse at a later date which can shorten the duration of compilation as if there is no change, the cached version can be used again.
We've been trying to make cache times as short as possible and realized that some of the steps of creating a cache archive can be eliminated. So instead of
- copying cacheable files into it,
- creating a map json file which contains which file has which path and the fingerprint info,
- creating an archive in place
- and uploading,
... we can make an archive with only 2 simple steps, by
- adding cacheable file straight to the archive plus adding the file info json created in runtime as the latest file,
- uploading.
This way we could decrease the number of steps from 4 to 2. This results in ~40-80% faster archive creation time! Cool! 😎
Graphic content! 🙈
In the following graphs you can check the comparison of the time required for performing the caching processes. We've run several tests with medium data density files to show you the swiftness of the new versions and let you see realistic average times.
1. Processing times for the initial cache (nothing was stored previously)
2. Duration of download and extract times
Thanks to the new Cache:Push method, we could get rid of some processes here as well. Previously we downloaded the archive to a tmp dir, then extracted it in place, finally started to copy the files to its locations (from the cache info a file). Now the step starts to download the archive, reads it into the memory and starts to write its files straight back to its locations at the same time.
3. Build no. 1+ (there are cached files available)
These are the durations of refreshing previous cache file content. The speed improvements of the changed cache is the most significant of all.
We’ve seen in hundreds of build logs that refreshing cache is sometimes inevitable. As now it takes significantly less time, you can have the cache refreshed for every build, if you want to, without making the build so much longer.
Happy caching! 💵
