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" <email@hidden>
- Date: Mon, 26 Jan 2009 22:09:56 +0000
On 26 Jan 2009, at 21:23, Ben Trumbull wrote:
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.
I think Shark has more going for it than the Instruments sampler
instrument.
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.
What I mean is if a object has a to-many relationship (lots of
children say faulting to one parent) but the faulted object has
already been retrieved from the store and is in the moc, will the in
memory resolution of that fault still trigger the KVO machinery? Or is
my head full of noodles this evening.
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
This could be the source of my original problem. I have been using -
setPrimitiveXYZ in -awakeFromInsert but not in -awakeFromFetch. So
that looks like it could be a howler.
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.
I was wondering about this - especially as I am occasionally getting a
curious EXC_BAD_ACCESS when rebuilding my NSAttributed string (but
that's another post).
To me appear that there are 3 ways to do this:
1. make the string rep after the fetch.
2. cache it in the db as you say.
3. use an NSValueTransformer in the binding.
The RTFD is more or less static so maybe caching it in the db is the
simplest and has the same memory footprint as the build on fetch
approach.
Thanks for your interest. Very much appreciated.
Jonathan
- 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