
Gilt Tech: Tips for optimizing iPhone/iPad applications - mwunsch
http://tech.gilt.com/post/3187131303/tips-for-optimizing-iphone-ipad-applications
======
robterrell
"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
It 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
John 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-
discus...](http://bethblog.com/index.php/2010/10/29/john-carmack-discusses-
rage-on-iphoneipadipod-touch/) (Under "Technical Geek Details")

------
danilocampos
Emphatic agreement about NSDateFormatter. Be careful about instantiating too
many of those.

I wrote an import class to map some JSON to Core Data entities, including a
boatload of dates. NSDateFormatter instances were being created during several
loops, at a cost of about 800ms, according to Time Profiler.

Refactored the code to use a single instance, shared across every object and
method that needed to do date parsing or other date chores. Shaved that 800ms
down to about 90.

Check your Cocoa codebase for NSDateFormatter abuse – really easy win.

Another win: Have your server vend binary Plist files instead of JSON or XML.
Zero parsing needed, similar file sizes. Cut import times as much as 50%!

------
seanalltogether
I'd be more interested in finding out why they're using so much threading and
locks in what appears to be an image gallery app.

~~~
nevster
It's common to have threads in UI apps so that things don't lock up. Eg having
a thread to download/process images and displaying them asynchronously.

~~~
seanalltogether
asynchronous downloading is built in to frameworks already and uiview
manipulation should happen on the main thread.

