Don’t underestimate how slow the disk really is

You should not treat every piece of data the same way. Here’s why

Alright, no additional introductions this time — I’ll just cut straight to the point:

Only, only request a data in a synchronous manner if it’s coming directly from memory.

What do I mean by that? Well, if you have, for example, this code in your app:

let user = persistence.getUser(for: id)
label.text = user.name

You need to be absolutely sure that this data is already stored in the memory. It’s not being retrieved from the disk. It’s not being deserialized. It’s not being resolved in an algorithm of a skyrocketing complexity. It’s just there. getUser needs to just pass you the data which is already in place, period.

Why?

Well, because anything other than RAM is way too slow. For some reason, we think that our iOS devices are faster than they actually are. Just to clarify — in order to achieve a smooth 60 frames-per-second UI, every main thread-related operation needs to take less than 16 milliseconds. 16 milliseconds!

Trust me, reading raw data from disk, parsing it to JSON and then to your model instance is not fast enough for 16 milliseconds task, even on the newest devices.

Thus, again, the point is: leave the synchronous mechanisms to instantaneous memory. For anything else, you must use asynchronous interfaces. I know it’s inconvenient. It’s harder to implement. It’s frustrating and it’s making the process significantly more complex. But it’s the right thing to do.

Of course, most developers know that. Nobody in their right mind would say, fetch images from disk to populate them in a table view on the main thread. They would either implement a simple memory caching solution for images, or they would use a library which does just that.

The devil is, of course, in the details. Let’s get back to our example:

let user = persistence.getUser(with: id)

Sometimes, our own conventions about the nature of such requests are too vague. We may implement getUser in such manner that sometimes it would retrieve the data from the memory, and sometimes — from the disk (depending on a state of your memory cache, for example). And we would think that it’s “good enough”.

It’s not.

To design a system that would hide from you whether or not there was any I/O involved for your request and not make your life miserable is an extremely difficult task. Basically, that’s what Core Data is doing. That’s what Core Data is very good at. But Core Data is a very sophisticated piece of technology, designed from the ground-up to enable this kind of behavior. It’s very smart, it makes a lot of presumptions about how and when the data will be needed, it tries to predict every move of your app (and most of the times succesfully). That’s, actually, one of the reasons Core Data is such an important tool for every iOS developer, also being the secret behind the smoothness of Apple’s own iOS apps.

You need to be extremely transparent in your codebase of where your data is coming from. If you want a responsive iOS app — make a majority of data calls asynchronous. If you don’t want to change your whole app to use asynchronous paradigms — use Core Data. Or try to implement something as smart as Core Data in terms of performance specifically for your app — it can be a lot of fun!

But don’t fool yourself into thinking that disk is fast enough, even if it’s hit rarely.

Thanks for reading the post! Don’t hesitate to ask or suggest anything in the “responses” section below. You can also contact me on Twitter or find me on GitHub. If you have written a piece (or stumbled upon one) exploring similar topic — make sure to post a link to it in the responses so I can include it right below.

Hi! I’m Oleg, the author of Women’s Football 2017 and an independent iOS/watchOS developer with a huge passion for Swift. While I’m in the process of delivering my next app, you can check out my latest project called “The Cleaning App” — a small utility that will help you track your cleaning routines. Thanks for your support!