5 ms·
"Not only does this new technique perform better, but by using this method to reference images, the OS has the option of purging image data from memory and reco
by robterrell 16y ago
"Not only does this new technique perform better, but by using this method to reference images, the OS has the option of purging image data from memory and reconstituting it directly from the file on an as-needed basis."
Luckily, that's an option it never takes.
"(Whether or not a given version of iOS does this is another story, but at least this technique gives the OS that option.)"
Does any version of iOS that has ever shipped do this? It sounds like wishful thinking. You're just hoping Apple will skate iOS to your puck.
It seems like a terrible idea, given how the rest of the memory management works. How does the OS determine that you actually need the image? And what if, at that moment, it can't be reloaded because the app is out of memory, the file was deleted, what if the file was overwritten, etc?
I'd guess that imageWithContentsOfFile: itself calls dataWithContentsOfFile: rather than something secret or magical, so I'm curious about how much of an actual optimization there is.
- swift 16y agoIt really doesn't seem like a terrible idea at all to me; why NOT use demand paging-style memory management for immutable images like UIImages? This is one of the things that virtual memory is good for. Apple seems to agree. From the documentation for UIImage in the iOS Reference Library (which as far as I can tell is a public page and not under NDA): "In low-memory situations, image data may be purged from a UIImage object to free up memory on the system. This purging behavior affects only the image data stored internally by the UIImage object and not the object itself. When you attempt to draw an image whose data has been purged, the image object automatically reloads the data from its original file. This extra load step, however, may incur a small performance penalty."
- corysama 16y agoJohn Carmack has mentioned some interesting ideas for keeping large, immutable resources in memory-mapped files on the iPhone. http://bethblog.com/index.php/2010/10/29/john-carmack-discusses-rage-on-iphoneipadipod-touch/ http://bethblog.com/index.php/2010/10/29/john-carmack-discus... (Under "Technical Geek Details")
- comex 16y agoA moment with IDA shows that it calls CGImageSourceCreateWithFile, which calls mmap, which supports exactly that kind of paging. However, dataWithContentsOfFile: also calls mmap under certain circumstances, so paging should theoretically be possible with either selector.
- kenferry 16y agoYes, it does take advantage. As of OS version 3, if an image is not retained by anything other than the UIImage named image cache and the app receives a low memory warning, the in-memory image is destroyed. -Ken (Cocoa Frameworks)
- masklinn 16y agoAnd this is clearly and publicly documented behavior, as quoted (but not linked) by swift above: http://developer.apple.com/library/ios/#documentation/uikit/reference/UIImage_Class/Reference/Reference.html%23//apple_ref/doc/uid/TP40006890-CH3-SW2 http://developer.apple.com/library/ios/#documentation/uikit/... > In low-memory situations, image data may be purged from a UIImage object to free up memory on the system. This purging behavior affects only the image data stored internally by the UIImage object and not the object itself. When you attempt to draw an image whose data has been purged, the image object automatically reloads the data from its original file.
- kenferry 16y agoThat's actually separate. That's talking about a UIImage purging data, but in this case, it's the entire UIImage that is discarded from the cache that holds UIImages indexed by name.
- masklinn 16y agoOh ok, I had missed that part. So the purging can happen at both level, within the UIImage (which discards its data when it's linked to a file) and within a cache holding a UIImage (which discards the UIImage itself)? (the former seemed to match the described case exactly, which is probably why I missed the difference, sorry)