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 :-)
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.