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: Colin Cornaby <email@hidden>
- Date: Fri, 24 Feb 2006 14:05:06 -0800
On Feb 24, 2006, at 1:45 PM, Bill Bumgarner wrote:
On Feb 24, 2006, at 1:16 PM, Colin Cornaby wrote:
10,000 objects is considered to be a pretty small dataset in the
database world. Unless your objects have really large chunks of
binary data stored within, 8,120 objects should be quite quick to
work with. SQLite can scale to terabyte sized databases with
billions of rows/tables/columns.
Given the size of the data set and the desire to work with it in
memory, I would suggest simply fetching all the objects into memory
at once. This could be done with a single fetch request in the
main thread. If that proves to be too time consuming, then move it
to a separate object context (against the same store) in a
background thread and then pass the objects into the main thread
via their global ID, as needed.
See the archives for numerous discussions of threaded Core Data apps.
However, don't bother with threads until you have:
- proven that performance with your data set is a problem in a
single threaded app
- optimized your data model
Right. I was under the impression that CoreData was only good for
handling smaller databases. I was also brought up under the CS dogma
that disk access should be avoided at all costs, so I'm trying to get
them off disk once and read them from memory as much as possible
afterwards. I had the database at 2000 items approx and the app felt
very responsive. With 8120 it does feel a bit laggy. A second thread
would just be used for caching the resources in the background
quietly while the user continues to use the application. I'm just
querying the entire database for one object type without any
predicate so the data model design probably isn't too relevant in
this case, although I've already gone through and optimized the modal
for more complex queries.
It caches objects in memory as they are accessed or fetched,
including "faulting in" objects on the other side of
relationships. Objects may or may not be cached for the lifetime
of the app depending on usage patterns. API is available for
optimizing the caching patterns and pruning object graphs.
Thanks, this database is only loaded up once in the entire lifetime
of the app, so i fI can make CoreData cache the objects indefinitely
this would solve my problem without creating memory use concerns.
I would suggest reviewing the Core Data documentation, concept
guides and examples. Core Data is designed to manage the in
memory cache vs. on disk store extremely efficiently. Certainly,
as a generalized implementation, there will be specific usage
patterns that are sub-optimal, but that is relatively rare and can
often be addressed through changes, often minor, to the object model.
Given that this application is being given to end users who probably
don't want to feel they are querying a database. I'd like to optimize
for speed vs. memory and disk usage. Like I said, this database is
only loaded in once on application launch, and in general only used
for reading, not writing, so I don't want to be bound to the disk
access speeds.
b.bum
Thanks for the pointers,
Colin
_______________________________________________
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