re: Processing data maintained with Core Data
re: Processing data maintained with Core Data
- Subject: re: Processing data maintained with Core Data
- From: Ben Trumbull <email@hidden>
- Date: Fri, 27 Mar 2009 23:04:11 -0700
Brief background: I'm porting an audio generation system to Mac OS.
The code for generating audio is in C and has run on a couple of other
OSs. It's been reasonably straight forward to model the parameters for
this system with Core Data, and I'm excited about getting CD to handle
multiple Undo and all that sort of stuff for me.
Wwhat I'm not clear on is if there is a "best practice" for
communicating the state of the object graph with the processing code
(in my case, the audio generator). The data model consists of a main
entity with something over two dozen parameters, and has a to-many
relationship with a second entity that encapsulates information about
soundfiles that are played back and mixed in real-time.
In this case, you'll want to use the prefetch & prepopluate options on
NSFetchRequest aggressively to avoid firing any faults when the RT
thread is depending on you.
One obvious approach would be to modify the existing C code to access
the parameters from the object graph each time through the audio
processing loop. Aside from the fact that that would mean rewriting a
big chunk of the existing audio generation code, I'm a bit leary of
the overhead of using KVC/KVO from the audio processing thread. But a
major rewrite would be sort of a deal breaker.
Well, you wouldn't be using KVC, since you have modeled objects.
You'd use properties. Assuming the audio processing thread is not
changing the data, it won't suffer KVO overhead either.
The getters of @dynamic properties for Core Data objects are very
fast, less than the cost of 2 ObjC message sends. This is roughly 7 C+
+ virtual method calls, or 11 C function calls.
So you can do something ~100 million @dynamic property gets per second.
When I saw mogenerator, I thought this might be a useful tool for my
task. I thought I could use this to override the default setter
accessors to communicate changes in parameter settings to my existing
code (and then call [super set<Key>]). But this would mean that I
would have two copies of each property (one in the object graph and
one in the back end code). In principle I avoid duplicate data, but
maybe in this scenario it's not that evil. OTOH, there has been
criticism of mogenerator, for instance
<http://www.cocoabuilder.com/archive/message/cocoa/2008/10/5/219503>
Given your existing code base, and RT constraints, I would suggest you
consider pushing changes over to the RT thread in batches. Basically,
update the configuration the RT thread is using in response to the
NSManagedObjectContextDidSaveNotification.
- Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden