Re: Progmatically Caching Objects from a CoreData SQLite Store?
Re: Progmatically Caching Objects from a CoreData SQLite Store?
- Subject: Re: Progmatically Caching Objects from a CoreData SQLite Store?
- From: Chris Hanson <email@hidden>
- Date: Fri, 24 Feb 2006 14:13:11 -0800
On Feb 24, 2006, at 1:16 PM, Colin Cornaby wrote:
I'm working with an extremely large CoreData database, containing
at present 8120 managed objects.
What do the entity descriptions of these managed objects look like?
Generally speaking, 8000 objects isn't a large object graph.
It's currently a SQLite store, except I would like to have the
entire object tree available in memory for access in order to speed
up the user experience.
Are there performance issues with your current user experience and
performance data (Shark traces) that lead you to believe this would
be worthwhile? Core Data performs its own caching, and Core Data's
faulting behavior will also work to pull only the objects that are
being worked with into a managed object context.
Rather than implementing a further layer of caching on top of Core
Data, perhaps it would be worthwhile to try normalizing your model
more. Core Data will retrieve all of an object's attributes when
fulfilling a fault, not just the attribute being accessed. For
example, if you're storing images or large amounts of text in
attributes, these should be split out into their own entity and
related to the original entity instead.
I'm assuming CoreData caches objects in memory as they're accessed
and writes back to drive as needed, but it seems to me if this
caching does exist the objects don't seem to be cached for the
entire lifespan of the application.
As I said above, Core Data performs its own caching. It will save
changes to persistent stores when you ask a managed object context to
save. (It doesn't write as a side-effect of just changing objects,
which your statement above could be read as implying.)
The lifetime of objects cached by Core Data shouldn't matter to an
application, and it definitely shouldn't need everything in a
persistent store to be cached in memory to perform well. In fact,
the opposite is often true; an application should have in memory only
what it needs to have in memory.
Does anyone know of a good way to build a cache in memory of an on
disk store? Creating an in memory store and copying each object in
one by one seems like an awful way to do it. Attempting to add an
in memory store to the persistent store coordinator just seems to
raise issues when I try to save. So I'm just looking for general
pointers on how maybe other people have dealt with this issue.
The best approach is to leverage the tools in Core Data -- faulting,
relationships, fetch requests -- to achieve your performance goals.
For more information, see the Core Data Programming Guide sections
"Faulting and Uniquing" and "Performance" here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
Articles/cdFaultingUniquing.html#//apple_ref/doc/uid/TP30001202-185436>
<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
Articles/cdPerformance.html#//apple_ref/doc/uid/TP40003468-SW1>
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden