5 ms·

It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be i

by liuliu 13y ago

It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.

conradev 13y ago
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.
- Groxx 13y ago
  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.
  - michaelmior 13y ago
    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.
  - mallorypaine 13y ago
    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.
    - Groxx 13y ago
      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.
    - nielsbot 13y ago
      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 https://github.com/nielsbot/Profiler (yes, I'm plugging my own code :-)
malkia 13y ago
Wondering if there is any support for PVR compressed images(2bit/4bit)?
skyebook 13y ago
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.
- nielsbot 13y ago
  that can work depending on how many images you have... Note also that there's a decompression hit loading PNG too.
- liuliu 13y ago
  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 :)
  - skyebook 13y ago
    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)
pugz 13y ago
It might vary depending on the image format. http://imageoptim.com/tweetbot.html http://imageoptim.com/tweetbot.html < This indicates that the disk throughput is more of a limiting factor than anything.

by liuliu 13y ago

conradev 13y ago

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.

Groxx 13y ago
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.
- michaelmior 13y ago
  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.
- mallorypaine 13y ago
  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.
  - Groxx 13y ago
    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.
  - nielsbot 13y ago
    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 https://github.com/nielsbot/Profiler (yes, I'm plugging my own code :-)

malkia 13y ago

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

skyebook 13y ago

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.

nielsbot 13y ago
that can work depending on how many images you have... Note also that there's a decompression hit loading PNG too.
liuliu 13y ago
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 :)
- skyebook 13y ago
  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)

pugz 13y ago

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