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: Robert Walker <email@hidden>
- Date: Thu, 3 May 2007 10:22:40 -0400
First my own disclaimer: I'm not an absolute expert at Core Data, but
I do have pretty extensive experience with the Enterprise Objects
Framework in WebObjects from which (at least in concept, not
necessarily code) much of Core Data derives.
1. Core Data is not inherently thread safe. To use Core Data in a
background thread, you have to use a context for each thread (or
use a huge lock all over Core Data but we don't go there. Besides
Bindings don't lock anything...)
Yes, I imagine that you're correct EOF is similarly not inherently
thread safe. Locking and thread safety, I'm sure, would be
exceedingly complex and difficult to get right in a system as complex
as Core Data. However, I'd be willing to bet that Core Data provides
a better developer and end user experience than most developers could
implement themselves. Not to mention the tremendous amount of
development effort required to support the feature provided by Core
Data.
2. To share new objects or object changes/deletions to other
contexts, one has to save the context. All new/changed/deleted
objects are propagated to disk by the store coordinator. Once the
objects are on disk they are accessible by the other contexts.
Again this is correct. This is, at least in part, how Core Data
manages undo and redo. If changes to one context affected all other
contexts, change management would be extremely difficult if not
impossible.
3. This can take a while (especially with an SQL store).
This statement seems to be a bit inaccurate. The SQLlite persistent
store is the fastest of all the provided disk based stores. The only
one that is likely faster is the in-memory store, which is obviously
not persistent once the application terminates.
4. The context seems to lock the store coordinator during a save!!!
(ouch!)
I can't seem to think of any applications that allow you to do
anything else while saving files. I guess I just don't see your
point here. Core Data is designed for speed. If you are having
performance problems, my guess would be that you are either misusing
Core Data, or your data is not well suited for use in Core Data. I
would suspect Core Data wouldn't be appropriate for things like video
formats, raw photo data, etc.
5. The data of an object is not automatically obtained from the
store. When the data is accessed and it's not there, it then is
obtained from the store. This is called a fault, firing a fault or
faulting. (I haven't got the hang of this part of the terminology yet)
Core data has a faulting system specifically for performance
reasons. If you have 20 different classes of objects stored in a
SQLite store and these objects have relations to each other, why
fetch the entire store into memory? If you just want to display
objects from one or two of the classes just fetch those.
Example: if you have people stored in the Person class and each
person belongs to a department. Now you have an interface that lists
people, but has no need to display their department information.
Core data will represent the departments using faults, rather than
actually fetching the departments from disk. Later a screen is
displayed that needs to know about department information, Core Data
will then automatically manage retrieving that data as it needed.
This greatly reduces the amount of code required by the developer.
6. The context locks the store coordinator during the firing of a
fault (at least partially).
Again this is necessary because the alternative would drastically
increase the complexity of Core Data.
7. Bindings tend to sometimes access an object's data at surprising
(or at least uncontrollable) times.
Maybe, but the Cocoa binding system is one of the most convenient,
and coolest, development technologies I know. It's one of the
aspects of Cocoa that has allowed the production of some of the most
advanced, and sophisticated applications, that have ever been
produced. I would say that the access to objects data is only
surprising to those who don't understand bindings. First, understand
the binding system, and then maybe you wouldn't be so surprised by
how bindings access data.
P.S.: Locks are like tanks - powerful, slow, safe, expensive, and
prone to getting you stuck. --- http://ridiculousfish.com/blog/
archives/2007/02/17/barrier/
And tanks are absolutely necessary in modern warfare. ;-)
On May 3, 2007, at 6:03 AM, Ruotger Skupin wrote:
Hi,
Disclaimer: I am being heretic up-front to pique your interest, no
offense meant, of course.
Ok, I'm trying to put the facts down systematically, please correct
me on any point if I'm wrong:
1. Core Data is not inherently thread safe. To use Core Data in a
background thread, you have to use a context for each thread (or
use a huge lock all over Core Data but we don't go there. Besides
Bindings don't lock anything...)
2. To share new objects or object changes/deletions to other
contexts, one has to save the context. All new/changed/deleted
objects are propagated to disk by the store coordinator. Once the
objects are on disk they are accessible by the other contexts.
3. This can take a while (especially with an SQL store).
4. The context seems to lock the store coordinator during a save!!!
(ouch!)
5. The data of an object is not automatically obtained from the
store. When the data is accessed and it's not there, it then is
obtained from the store. This is called a fault, firing a fault or
faulting. (I haven't got the hang of this part of the terminology yet)
6. The context locks the store coordinator during the firing of a
fault (at least partially).
7. Bindings tend to sometimes access an object's data at surprising
(or at least uncontrollable) times.
So taken all this together: When your app does a lengthy save
operation in a background context, it can hang pretty easily
(spinning beach ball) while the save operation is under way.
To the list:
What is the best strategy around this problem?
To any listening Apple engineer:
Do you want me to file this as a bug?
Roddi
P.S.: Locks are like tanks - powerful, slow, safe, expensive, and
prone to getting you stuck. --- http://ridiculousfish.com/blog/
archives/2007/02/17/barrier/
_______________________________________________
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:
40mac.com
This email sent to email@hidden
--
Robert Walker
email@hidden
_______________________________________________
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