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 12:40:50 -0400
When I have about 6 Departments with about 20 000 Employees and I
delete a Department the consecutive save takes between 5-15 seconds
(on a PB G4 1.5GHz)!
Yes, EOF has exactly the same issue. In EOF the solution is to
remove the to-many side of the relationship as a class property and
handled relationship delete rules in code. Sorry, I don't know if
this same type of workaround is appropriate for Core Data as well.
Anytime there is potentially large numbers of objects represented by
a fault you must ensure that fault is never fired. This is not
considered a bug in EOF and I'm sure it's not considered a bug in
Core Data either. It is up to the developer to handle such situations.
At least in Core Data the effect is a "beach ball" situation. In
EOF, given the whole request-response cycle system and the HTTP
adaptor, it results some very unfriendly failures for possibly
hundreds of users at a time.
Point being that this is all part of understanding optimizations in
Core Data. If you do choose to have a one-way relationship, which is
sometimes necessary for performance reasons, you must be aware of the
consequences and limitations you must place upon yourself as you
develop code.
For more information on this exact issue read the section in the Code
Data guide on "Issues with Unidirectional Relationships." That can
be found in the "Relationships" section of the document. This gives
an example of using a unidirectional relationships, the limitations
when using them, and the extra work required. Unfortunately, this
section appears to discourage their use without explaining why you
sometimes want (or need) to use unidirectional relationships. It
sounds like you have run headlong into why they are sometimes needed.
On May 3, 2007, at 11:11 AM, Ruotger Skupin wrote:
Am 03.05.2007 um 16:22 schrieb Robert Walker:
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.
Ok. Let's take the Apple Employee-Department example.
My Employee has about 30 attributes. Those are numbers, dates,
small strings (< 200 char). No large strings, no blobs. It also has
three relationships.
When I have about 6 Departments with about 20 000 Employees and I
delete a Department the consecutive save takes between 5-15 seconds
(on a PB G4 1.5GHz)!
That can means a 5-15s hang! (beach ball, no menus, nothing...)
Since I try to do everything on a background thread, I'm down to
cutting at most 10 relationships at a time in-between saves. Save
time goes down to 300-400ms. Blocking that long already makes the
app feel sluggish but it's still usable.
(Cutting relationships seems to be a lot more expensive, then
deleting objects upon save. weird.)
Maybe Core Data should not be used with more than one context at
all, due to the high costs of propagating new/changed/deleted
objects between contexts via saving.
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/
And tanks are absolutely necessary in modern warfare. ;-)
as are locks in modern multicore processor environment... <sigh>
--
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