2-5x faster cache steps, update now!

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!

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

  1. copying cacheable files into it,
  2. creating a map json file which contains which file has which path and the fingerprint info,
  3. creating an archive in place
  4. and uploading,

... we can make an archive with only 2 simple steps, by

  1. adding cacheable file straight to the archive plus adding the file info json created in runtime as the latest file,
  2. 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! 💵

No items found.
The Mobile DevOps Newsletter

Explore more topics

App Development

Learn how to optimize your mobile app deployment processes for iOS, Android, Flutter, ReactNative, and more

Bitrise & Community

Check out the latest from Bitrise and the community. Learn about the upcoming mobile events, employee spotlights, women in tech, and more

Bitrise Insights

Cache | Caching

Mobile App Releases

Learn how to release faster, better apps on the App Store, Google Play Store, Huawei AppGallery, and other app stores

Mobile DevOps

Learn Mobile DevOps best practices such as DevOps for iOS, Android, and industry-specific DevOps tips for mobile engineers

Mobile Testing & Security

Learn how to optimize mobile testing and security — from automated security checks to robust mobile testing and more.

Product Updates

Check out the latest product updates from Bitrise — Build Insights updates, product news, and more.

The Mobile DevOps Newsletter

Join 1000s of your peers. Sign up to receive Mobile DevOps tips, news, and best practice guides once every two weeks.