When Cheap isn't cheap anymore.

During my time in my previous company, I've learned a lot, but here are two: (1) New APIs aren't always the right fit - diffable data source is great for partial updates, not full replacements. (2) 'Cheap' operations aren't cheap at scale - profile before you assume.

I've been tasked with handling real-time data using web sockets. On paper, the feature was easy. Instead of stopping at 10 price levels, show all of them - which could be anywhere between 80 to 137 price levels depending on the stock. During peak hours, the view that was responsive suddenly became frozen. Users couldn't scroll up and down, and unfortunately, this happened only during peak trading hours, so it slipped through QA.

I thought Diffable Data Source would fix it. I implemented it based on data associated with UUID, but it just made things worse. The issue is that the data sent isn't a snapshot of changes but the entire list of price levels. Diffing the entire list every time was pure overhead - no partial updates to optimize for. In this case, using tableView.reloadData() is faster.

Then I fired up the profiler to find the real bottleneck. Looking through the results, I was quite surprised. The computed properties - like color for up and down, and the number formatting - were clogging the main thread. The computations were cheap, but when hit with 30 packages per second, each carrying all price levels, they weren't cheap anymore. Even the localization we take for granted can clog up the main thread.

• Before: 5 levels × 30 updates/sec × (formatting + color calc + localization) = manageable

• After: 100 levels × 30 updates/sec × same operations = UI death

The solution is relatively straightforward: no more calculations on computed properties. All properties are calculated in background threads when converting the WebSocket response into view data. The view becomes dumb - it just reads values from the view data. After the changes, it managed to survive peak trading hours with smooth scrolling.

Now when we hit performance issues, we know where to look first.