small medium large xlarge

Back to: All Forums  Core Data
21 Sep 2009, 13:14
Douglas Mayle (1 post)

In the book’s multi-threading example, it’s creating an NSManagedObjectContext in the main method of the NSOperation. If I have a number of NSOperations running one after the other, will there be a large overhead creating the context with each task?

With the NSOperationQueue having a max concurrent operation count of 1, many of my operations will be using the same thread. Can I use the thread dictionary to create one NSManagedObjectContext per thread? If I do so, will I have problems cleaning up my contexts later?

What’s the correct way to use Core Data in this instance?

22 Sep 2009, 14:48
Marcus S. Zarra (284 posts)

Create one per operation. The stack (above the persistent store coordinator) is fairly lightweight and the overhead is minimal.

Wedding photobooth_pragsmall
15 Nov 2009, 12:29
Tony Arnold (11 posts)

Sorry to hijack this a little - but under what circumstances is it appropriate to spin off a new context? I’ve started doing it for my custom controllers, and using mergeChangesFromContextDidSaveNotification to roll everything back into the “main” managedObjectContext attached to my application’s delegate - is this the right way to go about this, or should I just be referencing the app delegate’s moc?

My reading so far suggests what I’m doing is right, but I could use some reassurance :)

17 Nov 2009, 17:22
Marcus S. Zarra (284 posts)

The answer to that question is: it depends.

First and foremost, do not pre-optimize your application. It is never a good thing.

Once your application is written, profile it and find the hotspots. If you find that processing a portion of your data model is a hotspot then consider threading it. But it is a waste of time to throw something into a thread or NSOperation and fine out it takes 1/10th of a second to process.

You must be logged in to comment