When Cheap Operations Aren't Cheap at Scale in Apps

During my time in my previous company, I learned valuable lessons about performance scaling, particularly that new APIs aren't always the right fit and operations considered cheap can become expensive at scale. This challenge began when I was tasked with handling real-time data using WebSockets. On paper, the feature seemed straightforward: instead of stopping at 10 price levels, the application needed to display all of them, which ranged anywhere between 80 to 137 price levels depending on the specific stock.

During peak hours, the previously responsive view suddenly froze, preventing users from scrolling up and down. Unfortunately, this issue manifested exclusively during peak trading hours, allowing it to slip past the QA process. I initially believed that implementing a Diffable Data Source based on UUID-associated data would resolve the bottleneck, but it only exacerbated the situation.

Stock photo for illustration only, not from the actual event

The core issue stemmed from the incoming data payload, which transmitted the entire list of price levels rather than a snapshot of incremental changes. Diffing the entire list repeatedly introduced pure overhead without any partial updates to optimize. In this specific scenario, utilizing tableView.reloadData() proved to be significantly faster, prompting me to fire up the profiler to uncover the true system bottleneck.

A deep dive into the profiler results revealed surprising culprits. Computed properties—such as color calculations for price movements and number formatting—were clogging the main thread. While these computations were cheap individually, encountering 30 packages per second, each containing every price level, transformed them into severe performance blockers. Even standard localization tasks contributed to freezing the main thread.