Question

I had memory problems with an universal iOS application: CoreData was using too much memory (> 30 Mo). Thus I did everything I could to reduce the amount of memory used.

Basically my CoreData model is a basic catalogue model:

• high level categories (entity with limited binary data <10K)
• each category has ~10 subcategories (entity with limited binary data <10K)
• each subcategory has ~10 products (again, limited binary data <10K)
• each product has ~10 detailed pictures (with a higher amount of data: ~40-70K)

After each item’s detailed item (including pictures) is deallocated, I do a

[NSManagedObjectContext refreshObject:item mergeChanges:NO];

call to reduce the in-memory graph (in order to skip pictures)

Things work pretty well with iOS 5+ but with iOS 4.3, I get many errors.

Sometimes, the error is :

Terminating app due to uncaught exception
‘NSObjectInaccessibleException’, reason: ‘The NSManagedObject with
ID:0xbb70480

has been invalidated.’

Other times, the app is killed with “handler threw exception” and no details on what went wrong.

My questions are :

• Any idea why the behavior is different from iOS 5 and iOS 4.3?
• Any recommandation on what I could do the reduce the memory used by CoreData? (other than releasing fetch controllers and releasing contexts that are not used anymore)

Answer 1

Hard to say the specific differences in memory usage w/ your model in different iOS versions. In my experience, storing images in a core data store doesn’t work particularly well. Generally, you want image data in memory only when needed. Each of your categories has ~4-7MB of image data so it won’t take too many categories before you run into problems. What I did in my app was store image data on disk and store the filename in the store. The image is only loaded when needed for display and it is released when no longer needed. This keeps the store small and fetches are fast.

If you want to keep the image data in the store you should optimize as best you can. Configure all of your fetch requests to get all properties except the image data so that the image is faulted in when needed. You’ll also need to ensure the image data is turned back into a fault when not needed.

EDIT: more info on why storing image data in core data is bad

Another problem with using core data to store image data is that loading and saving the data, even if done only when needed, takes a non-trivial amount of time and will block your main thread while loading. Wherever you store the image data, you want to load it from the background. That’s simple if using a file store. If using core data, implement background image loading/saving logic that creates a new context, loads/saves the image data. When loading this would need to pass the data to the main thread so the UIImage can be created/displayed.