views:

383

answers:

2

Hi there,

I've read the memory management sections in the Core Data docs and I'm still a little confused. I have one context in my app, and I have several things getting objects out of it. For example a few fetched results controllers, detail views and some other code fetching random objects. Once objects have been fully released and their retain count is 0, will core data automatically release all the object information and fault them?

I'm pulling lots of data into my context in some of my fetched results controllers, and I want to make sure that after the user has finished scrolling and perhaps has drilled down into another view, will those objects that were fetched when scrolling the tableview be released and faulted back to the store?

Many thanks,

Mike

+2  A: 

Yes, CoreData will fault things back that you are not using. It has caches and various other things, so the data might not be released immediately, but in general it is very good about memory management and dealing with keeping its footprint as small as possible.

If you have a particularly odd usage profile you can explicitly force objects back into faults, but that is generally not necessary, and I would not consider doing that unless I actually had some actual profiling data saying I was under memory pressure.

Louis Gerbarg
Thanks, I just wanted to make sure that the fetched results controller wasn't going to keep loads and loads of objects in memory after scrolling a long list and then that they'd stay there until the context is saved or cancelled!
Michael Waterfall
+3  A: 

Core Data manages object lifetimes the same way the rest of Cocoa manages object lifetimes: NSManagedObject instances in a managed object context are retained in memory as long as the managed object context or any other object retains ownership of them (via -[NSObject retain]. By default, the NSManagedObjectContext does not retain instances, so they are released as soon as any other owners (i.e. your NSFetchedResultsController instances or other instances in your program) release them. You can change this default behavior of the managed object context to retain instances, but you rarely want to. The managed object context has to retain instances that are updated until the next save. There's no way to preserve these changes except in the object instance until the context is saved. So, to minimize memory usage of Core Data objects, follow the standard rules: release them as soon as you can. If you find that your context memory usage is growing (use Instruments' Core Data instruments to track this), save the context more frequently if you are updating instances and hence keeping them alive in the context until the next save even if you've otherwise released them.

Using NSFetchedResultsController makes all of this easier. In fact, the reason NSFetchedResultsController exists at all is to make batch fetching in a low memory environment (like the iPhone) easier for the programmer.

As Louis mentioned, the NSPersistentStoreCoordinator maintains a row cache to cache instance data in memory instead of having to go back to disk when an object is faulted into the managed object context. This is a Core Data implementation detail, however (though cache misses are a performance hit; you can track cache misses in Instruments). Core Data manages the cache memory and you shouldn't have to worry about it.

Barry Wark