How We Sped Up Zipline Hot Reload
Article Summary
Cash App's team turned a frustrating 20-second hot reload into a blazing 2.7 seconds. Here's how they systematically hunted down every millisecond.
Yissachar Radcliffe shares how Cash App optimized Zipline, their library for fetching and executing Kotlin code compiled to JS in mobile apps. What started as a simple Gradle upgrade turned into a deep performance investigation across the entire hot reload pipeline.
Key Takeaways
- Upgraded to Gradle 7.5 and enabled incremental Kotlin/JS compilation (50% faster immediately)
- Fixed wasteful prod and dev builds running simultaneously (saved 4 seconds)
- Replaced Webpack with http4k static server and added websocket push notifications
- Split giant proto module dependency to eliminate 500ms QuickJS load time
- Disabled unused Dukat task that secretly launched Node processes despite being 'skipped'
Through systematic profiling and optimization, the team reduced Zipline hot reload from 20 seconds to 2.7 seconds, with all improvements merged upstream for the community.
About This Article
Yissachar Radcliffe noticed that QuickJS took about 500ms to load a single Zipline module with proto definitions, even though the app only needed a few of them.
The team broke up the large proto dependency module and added explicit dependencies for just the protos actually being used, which cut unnecessary code out of the hot reload pipeline.
Removing the bloated proto module shaved 500ms off the on-device load time and helped bring the overall hot reload speed down from 3.2 seconds to 2.7 seconds.
