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: Ben Trumbull <email@hidden>
- Date: Mon, 26 Jan 2009 13:23:13 -0800
On Jan 26, 2009, at 11:47 AM, email@hidden wrote:
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...
I'm not that old. For short events like launch time, I've found Shark
to provide much better accuracy than a lot of alternatives, plus free
samples as a bonus.
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.
Hrm. I suspect you have some custom observer code that's triggering
yet more work. Or it may be your custom -awakeFromFetch
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'm not sure what you mean by that last part. But if you have a to-
many relationship, and you need its contents at launch time, you
definitely want to use prefetching.
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].
You can use both. Plus, you'll probably want to prefetch the
relationship or not use it at launch time.
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.
How are you setting the results for these string reps ? I assume upon
transient attributes, yes ? If the array controller is bound to those
transients, this may be what it is observing. You could also try
using -setPrimitiveXYZ: instead of -setXYZ: during awakeFromFetch
If you need these for launch time, have you considered making them
persistent ? Unless the RTFD data changes frequently, you may be
better off caching the extracted strings in the db.
- 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