11–20 of 35 posts
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.
Whats the difference between this and SDWebImage, if any?? I cant see a ton of different API differences. Looks like this probably wont support ARC, though.
Earlier quoted context omitted.
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…
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)
I've since lost track of the Apple documentation that said it, but CA prefers 16-byte alignment and (kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Little) for the pixel format.
It's not using ARC. Is this legacy code, or couldn't they get equivalent performance with ARC enabled?
Whats the difference between this and SDWebImage, if any?? I cant see a ton of different API differences. Looks like this probably wont support ARC, though.
It's not using ARC. Is this legacy code, or couldn't they get equivalent performance with ARC enabled?
Hello. Mallory Paine here. I wrote FIC. This is not legacy code...it should be trivial to convert it to ARC and performance should be unaffected. I'm a bit old school myself so I chose to write it with manual retains. Does this approach make the code more difficult for you to use within an ARC project?
Earlier quoted context omitted.
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 m…
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.
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.
Earlier quoted context omitted.
Hello. Mallory Paine here. I wrote FIC. This is not legacy code...it should be trivial to convert it to ARC and performance should be unaffected. I'm a bit old school myself so I chose to write it with manual retains. Does this approach make the code more difficult for you to use within an ARC project?
Why would you write it with manual retains? Who doesn't use ARC at this point?