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
Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence.
The next time you need to store data, you should have a better idea of your options. Core Data is unnecessary for random pieces of unrelated data, but it's a perfect fit for a large, relational data set. The defaults system is ideal for small, random pieces of unrelated data, such as settings or the user's preferences.
Even though Core Data knows how to use a SQLite database as its persistent store, that doesn't mean you can hand it any SQLite database. The database schema of the SQLite database used by Core Data is an implementation detail of the framework. It isn't publicly documented and liable to change.
Core Data uses a schema called a managed object model — an instance of NSManagedObjectModel . In general, the richer the model, the better Core Data is able to support your application. A managed object model allows Core Data to map from records in a persistent store to managed objects that you use in your application.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With