Re: Does Core Data have a serious problem?
Re: Does Core Data have a serious problem?
- Subject: Re: Does Core Data have a serious problem?
- From: Ben Trumbull <email@hidden>
- Date: Tue, 8 May 2007 15:46:12 -0700
At 11:10 AM +0200 5/8/07, Ruotger Skupin wrote:
Changes and deletions can be exposed to other context before saving,
How? I didn't find it mentioned in the docs.
The problem with insertions is that the brand new objects are not
accessible to other contexts until they are saved. By accessible, I
mean semantically, as in their existence can't be communicated.
Until they are saved, the new objects don't have an identity (primary
key)
For updates and deletions, the objects have their permanent identity,
and you can use any of the standard Cocoa or OSX idioms for
communicating between threads to replicate those changes in a
different context.
Core Data doesn't have any additional routines for that.
However, Core Data offers the following on NSManagedObject:
- (NSDictionary *)committedValuesForKeys:(NSArray *)keys;
- (NSDictionary *)changedValues;
Also, NSManagedObject is fully KeyValueCoding compliant, and KVC has
a number of handy methods for pushing and pulling batches of changes:
-(NSDictionary *)dictionaryWithValuesForKeys:(NSArray *)keys
- (void)setValuesForKeysWithDictionary:(NSDictionary *)keyedValues
Maybe for an application that creates and deletes a lot of objects
in short bursts Core Data is not a good fit?
Well, I suppose the only correct answer is "that depends". The
problems I've seen with save performance are:
(1) Wrong granularity. Either saving too frequently without enough
data to justify the I/O, or not saving enough, and accumulating too
many pending changes in memory, bloating the heap size to the point
that it's bad for performance. These are, btw, the same kinds of
issues one would have with any kind of I/O.
(2) Problematic model design. At some point, an aesthetic and
normalized schema needs to give way to pragmatism. Some important
values need to be denormalized, and excessively fine grained objects
need to be rolled together into a single entity as attributes instead
of independent managed objects. Entity inheritance can be expensive,
so properties should sometimes be replicated, instead of inherited,
and use class inheritance instead of entity inheritance to make them
uniformly accessible at runtime.
(3) Fetch-or-create pattern for unique objects. Validating unique
column values is hard to do with good performance. Many people do
this by fetching repeatedly for each value. But that's basically
problem #1, just with fetching instead of saving. Ideally, one would
want to unique a batch of values together with one fetch using an IN
predicate.
There's at least one person on this list using Core Data for an
OpenGL application. Lots and lots of very small data for point
meshes. But those meshes are stored as NSData attributes, not
individual rows in the database. This is one approach to a pragmatic
model design for extremely fine grained data. For some ideas, you can
search the archives for "Core Data OpenGL" in February 2007.
If you total data set is small enough, you can also try using the
binary store, which is based on NSKeyedArchiver. It has different
performance characteristics than the SQLite store.
Since the binary store doesn't perform faulting to disk, some people
find it easier to get started with. The binary store's (and all
atomic archive formats) weakness is that it doesn't scale nearly as
well.
With some deft engineering, it's possible to get good performance out
of the SQLite store with many millions of rows. We have a number of
clients with multi-GB data files.
We also have some customers who actually want to burn memory so they
can meet soft real time constraints ... the different performance
characteristics between the in-memory, binary, and SQLite stores can
be leveraged creatively.
--
-Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden