Re: Core Data performance [Re: Knowing when a NSArrayController is ready]
Re: Core Data performance [Re: Knowing when a NSArrayController is ready]
- Subject: Re: Core Data performance [Re: Knowing when a NSArrayController is ready]
- From: email@hidden
- Date: Mon, 26 Jan 2009 19:47:43 +0000
On 25 Jan 2009, at 21:30, Ben Trumbull wrote:
The results for a default fetch on a data set of 1500 very simple
objects are:
XML - usesLazyFetching = NO 38.00 sec load
XML - usesLazyFetching = YES 4.78 sec load
SQLite - usesLazyFetching = NO 35.25 sec load
SQLite - usesLazyFetching = YES 2.07 sec load
These numbers are astronomically wrong. On a modern intel machine,
those numbers are off by between three and four orders of
magnitude. A 500Mhz ppc G4 with 256MB RAM can fetch 10,000 rows
over 20x faster than that.
Thanks for posting a reply, It put me on the right track.
I think the numbers show that it is trivial to get your Core Data
configuration astronomically wrong, especially if you are using
bindings.
Timings are Cro-magnon.
Why ? Put Shark in Time Sample (All Threads State). You'll get
close to wall clock time with a sampling accuracy of microseconds.
36000 years later...
Instruments reports:
1500 item data set fetch time .028s. So it's not the fetching that
takes time!
My simple timings included a LOT of KVO notifications, not just the
raw fetch.
Or just use the user default -com.apple.CoreData.SQLDebug 1 and
we'll log all the SQL, plus annotations for timings of fetching. It
even comes in color -com.apple.CoreData.SyntaxColoredLogging 1
Everyone needs to have this on.
What does Instruments say ? Select the Core Data template in the
new document window. That will configure all the most interesting
Core Data instruments together.
Typically, with the SQLite store the most common error is failing to
use prefetching when appropriate and faulting in lots of
relationships.
My model is very simple with only a single to-many relationship.
With usesLazyFetching = NO things go haywire.
I get 1500 faults each of which throws up a storm of KVO calls.
The docs do state (Core Data Guide - Faults and KVO Notifications)
that KVO notifications do occur as faults are realised, even if the
faulted relationship is already in the moc (is this last assumption
correct?)
I have a few bindings attached to the array controller which probably
accounts for the storm.
usesLazyFetching = YES seems to batch up the faulting so that the
notification storm doesn't get too out of hand.
However the best solution, in this simple case, is just to use
[request setReturnsObjectsAsFaults:NO].
The XML store takes a long time to parse and add to the coordinator,
but doesn't have that problem because it caches everything in
memory. So the fact you've managed to make the two perform about
the same implies something else is going on.
I am using NSPersistentDocument + GC therefore it would seem that I
have to revert to XML as per http://www.cocoabuilder.com/archive/message/cocoa/2008/2/28/200078
What are you doing in -awakeFromFetch for example ? What kind of
machine were these numbers taken on, and did you do so after a fresh
restart with no other apps running ?
-awakeFromFetch extracts strings reps of an RTFD data binary and
NSDate - so it does contribute to the load time.
Do you get the same performance without putting the objects in the
array controller ? Just set up the stack and do the fetch and toss
the results. Misconfigured array controllers can sometimes generate
notification storms if you add observers that make changes while
receiving notifications from the controller that something is
changing.
The com.apple.CoreData.SQLDebug user default above is handy for that
as what should be one or two fetches with a half page of log will
instead by a fire-hose of logging that makes you want to quit
Terminal.
- Ben
Jonathan Mitchell
Central Conscious Unit
http://www.mugginsoft.com
_______________________________________________
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