Core Data has (or, I should say, had, since I haven't investigated the
behavior in Snow Leopard) its own internal in-memory cache of object
and attribute data, which means that, up to a point, data from a
persistent store is in memory twice. AFAICT there's no way of
unloading or controlling this cache, which has a maximum size that
Core Data chooses.
So you can get back the memory occupied by the objects themselves (and
their attribute value objects), but your memory footprint could stick
at a couple of hundred MB. You could just ignore the issue (the
footprint won't grow beyond certain point, so it's sort of harmless),
or try some of the fetch performance optimization techniques described
in the Core Data documentation to see if you can keep unwanted
information out of the cache from the beginning.
The caching is happening at the NSPersistentStoreCoordinator level,
and is shared copy-on-write with the managed objects themselves (e.g.
faulting the same object in multiple MOCs will reuse the same string
data). The raw column data is not duplicated in memory. The cache
entries are deallocated after the managed object representing that row
is deallocated, and at certain other times involving faulting. Simply
releasing the last managed object representing that row is enough.
You may need to call -processPendingChanges to purge anything that as
accumulated as ready to be disposed to encourage this to happen sooner
if you find it's taking too long.
- Ben
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
