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 14:19:44 -0800
On Jan 26, 2009, at 2:09 PM, email@hidden wrote:
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.
The answer is ... it depends. It can demonstrate the behavior you are
concerned about.
If you are fetching lots of children, and traversing their parent
relationship, then you almost certainly will want to use prefetching
(setRelationshipKeypathsForPrefetching) which will instruct the fetch
request to resolve them all at once, with 1 additional I/O instead of
resolving them lazily one at a time for each child and N additional I/
Os.
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.
Also, don't underestimate the power of writing your own custom
NSValueTransformer. The default one used by transformable attributes
is NSKeyedArchiver, but while flexible and powerful, it can be a bit
slow for very small items.
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.
Caching in the db will provide a much better in memory footprint, at
the expense of more disk use, and potentially slower saves.
- 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