Core Data performance [Re: Knowing when a NSArrayController is ready]
Core Data performance [Re: Knowing when a NSArrayController is ready]
- Subject: Core Data performance [Re: Knowing when a NSArrayController is ready]
- From: Ben Trumbull <email@hidden>
- Date: Sun, 25 Jan 2009 13:30:53 -0800
On 24 Jan 2009, at 18:41, Matt Neuburg wrote:
On or about 1/24/09 10:17 AM, thus spake "email@hidden"
<email@hidden>:
I am also having horrible performance problems.
A data set of 1500 items with a total on disk size of 1.8MB is
taking
more than 30 secs to load.
Maybe NSArrayController -fetchWithRequest will improve things.
I would ask you the same question I just asked someone else on the
list: are
you using the XML persistent storage format? Because, if so, you
must expect
some delay, since even before you fetch any objects the entire XML
file must
be loaded into memory and parsed.
I use XML because I want human readability for my data, so startup
speed is
a sacrifice I am prepared to make. My data consists of about 5000
items, but
they are very simple; dealing with complex objects would take
considerably
longer, one assumes. In order to cave-man-instrument the startup
procedure
via NSLog, I do NOT prepare content or even bind my array
controller's
managed object content in the nib; instead, I do it all manually in
awakeFromNib. Here are some NSLog timings:
2009-01-24 10:37:09.157 [788] awakening from nib
2009-01-24 10:37:09.269 [788] binding to MOC
2009-01-24 10:37:09.359 [788] creating whole shebang
2009-01-24 10:37:09.360 [788] adding persistent store
2009-01-24 10:37:13.877 [788] calling fetch
2009-01-24 10:37:14.192 [788] done calling fetch
Notice the big delay between "adding persistent store" and "calling
fetch";
that consists a single line of code (calling
addPersistentStoreWithType:).
So the delay there is nothing but the XML file being loaded and
parsed. m.
Hi Matt
I decided to follow your example so I set prepareContent = NO and
called -fetchWithRequest:merge:error: from my controller.
I also switched between the XML and SQLite store types to see the
effect.
I also made use of -setUsesLazyFetching.
Timings are Cro-magnon.
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 = NO 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.
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.
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
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.
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.
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 ?
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
_______________________________________________
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