One thing that is often overlooked when considering file I/O is that the kernel caches previously accessed files for fast reads. This, combined with the lazy-loading mmap() can prove for good performance with simultaneous low memory usage for something like an image cache.

This technique is used on the iOS home screen - both the icon images and the rendered icon labels are stored as uncompressed bitmaps on disk and mmap'd when needed into memory. The fast loading allows SpringBoard to aggressively recycle icon views.

Does mmapping the file mean that it'll block on file I/O if it's not already cached, though? I don't see any claims (haven't read the code) that it prevents this.

When the pages are first accessed, the file data is paged in, and yes, this will be a blocking operation. One way to mitigate this would be to force the data to be paged in using a background thread, so that the pages are live by the time Core Animation needs those bytes to render the layer. This page preheating isn't usually necessary for small images, which is the primary use case for FIC.

FIC really pays off in a scenario like Path's mobile app. We have many, many small-to-medium-size user images to display, and those images are competing for CPU time with all of the styled text labels we're drawing. The less CPU we have to devote to images, the faster we'll be able to scroll.

Aaah, all the text rendering, that lends more weight to storing them uncompressed. Hadn't thought of that, I was pondering more on the I/O being way slower than (uncontested, in retrospect) CPU of basic decompression.

Well, Path is amazingly smooth for how much styled stuff is in it, so nice work :) The UI really does stand out in how well it's done.

I've used this to track down my scrolling performance problems in the past, although it's been a while: https://github.com/nielsbot/Profiler (yes, I'm plugging my own code :-)

Yes. If you mmap a file and then try to access it and it's not already in RAM, you'll block while the bit you're trying to access is paged in.

It actually isn't all that surprising, we've hit similar bottlenecks where JPEG decompression on the iPhone ends up choking feeds that are scrolled through quickly.

We didn't go the route of caching the uncompressed data on disk, though, we just keep the images in a maintained in-memory cache.

Exactly. I would think that a layered cache scheme probably could have the best of the two worlds (a good size of cached content on disk, and fast uncompressed image hit from memory). But using mmap'ed file instead of doing own layered cache seems less hassle. Also, you are doing decompression on a background thread, which shouldn't be much a choke on 4S and later devices (probably, again). I need to have some tests to backup my claims obviously :)

If you're using libdispatch on the 4S you might consider using a serial queue (for NSOperationQueue just set the maxConcurrentOperationCount to 1) as it starts to eat the CPU pretty quickly if you're trying to load a lot of images.

Even on the 5 I was surprised by how much it helped to have the images cached (no anecdotal data on the 5S as it came out way after we started caching)

that can work depending on how many images you have... Note also that there's a decompression hit loading PNG too.

It might vary depending on the image format. http://imageoptim.com/tweetbot.html < This indicates that the disk throughput is more of a limiting factor than anything.

Wondering if there is any support for PVR compressed images(2bit/4bit)?