Thanks to some patient help from this list, I now have a working Core
Data model. One object in the model is basically a glorified vector
polygon — an array of "point" structures that contain a about a dozen
doubles each. I insert a lot of these polygon objects, and often need
to draw all of them very quickly.
I originally included the point structures themselves in the model,
with a to-many relationship from each polygon to the points, and
sorted the points to their proper order in memory when necessary. This
was a bit slow, as Core Data seemed to fault each point object
individually, resulting in a lot of query overhead. So I switched my
polygon objects to have only one attribute: binary data for the point.
I thought this would result in significant speedup, but Core Data
faults my objects so often that now I spend even more time unarchiving
each polygon's point data than it took to read each point's row in
from the database!
I've thought about caching the result of my "get all polygons" fetch
to speed up redrawing, plus further optimizing my archiving code to
help initial load and final save speed. If I do this, my thought was
to watch the MOCObjectsDidChange notification for inserted/deleted
objects and update my cache when necessary. (By my understanding, the
updated objects will already be updated at my cached pointers.) This
seems a little icky, though. Does Core Data provide a cleaner way of
efficiently keeping a fetch result up-to-date?
Another issue with dealing with the points via a binary data archive
is the wasted memory. These polygons would be immutable if Core Data
allowed such a thing, so it seems especially wasteful to keep the
unarchived copy of the point array and the persistent data blob both
in memory. If I model a (prefetched) to-one relationship to the
polygon's binary data instead of an attribute, and [moc
refreshObject:binaryData mergeChanges:NO] once unarchived, will this
make it fairly likely I'll only have my unarchived copy of the point
array data in memory?
Or are the the above optimizations a bad approach to solving this
problem? I'd like to get a little closer to the "terabyte sized
database with billions of rows/tables/columns" advertised in the
performance section, but it seems that statement assumes I'm fetching
only a small fraction of those rows at once. For flat primitive data
like this, is it possible to get performance closer to a raw push of
the data to/from disk with Core Data?
thanks,
-natevw_______________________________________________
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
