Re: Basic Coredata / threading question

FROM : Jim Correia
DATE : Sat Apr 07 19:39:29 2007

On Apr 6, 2007, at 3:26 PM, Walt Horat wrote:

> I have an application that keeps a large model. The app fires off a 
> number of network queries in parallel - each of these is fired on a 
> separate thread. Each of these threads needs to access the model 
> when the response returns, and execute a fetch which will require 
> coredata to touch nearly every object in the model.
>
> It seems that if each thread is given its own managed object 
> context, the app will have N copies of the model all in memory at 
> the same time - this does not sound like a good strategy for large 
> datasets.


Seems is a good way to spend a lot of time optimizing the wrong code. 
Use the performance tools to take meaningful measurements, and 
optimize the code that matters.

In particular, if CoreData did work this way (it doesn't), the 
relevant question is does the usage patterns in your application make 
this a problem? If not, then you can spend that time working on other 
problems.

Many of the recent CoreData threading questions are answered in the 
documentation and/or recent posts to this list (which are available 
in the mailing list archive. I'll refer once again to

   http://lists.apple.com/archives/cocoa-dev/2007/Mar/msg00739.html

which says:

   Although each NSManagedObject instance is a distinct object between
   NSManagedObjectContexts, the actual data from the database is shared
   copy-on-write. So, for most apps, there is not a lot of memory to be 
saved
   by sharing managed objects anyway.

   If you keep managed objects and their contexts private to each 
thread, and
   use -objectRegisteredForID:, -objectWithID:, or -
executeFetchRequest: to
   "copy" managed objects between threads, you'll find yourself living 
in a
   much more maintainable and comprehensible threading model.

Jim