Re: CoreData/NSManagedObject accessor performance problems
Re: CoreData/NSManagedObject accessor performance problems
- Subject: Re: CoreData/NSManagedObject accessor performance problems
- From: Andrew Bush <email@hidden>
- Date: Sun, 17 Dec 2006 09:08:33 +1300
Hi Scott,
first I attempted this by adding a predicate to the
NSArrayController, but it appears to ignore the predicate when it is
bound?
It might be worth trying to debug this before trying other options.
so combining a predicate with the binding should work?
Instead of using selection directly, how about setting up a fetch
request with a predicate that matches your filtering options _and_
also has the proper relationship to the parent object. Does that make
sense?
yep. I can definitely give it a try.
the _really_ interesting thing is that repeating the filtering during
the same running of the program, after altering one of the values I
filter on and then calling [NSArrayController rearrangeObjects],
appears to be a hell of a lot quicker.
Because everything is faulted in, probably?
no, the value Im looking for isn't a faulted value, its just a standard
property(ies).
so, on the wild, random guess that the slowdown is probably caused by
some kind of serialisation being reversed for each initial call to
each value of each object I am wondering whether it would make sense
to create my own archiving strategy
That's a baby with the bathwater thing. A lot of people fall into the
trap of thinking Core Data/Bindings is an "all or nothing" or "as-is"
solution. It's not. There are plenty of opportunities for tweaking and
customizing. I humbly suggest investigating other options before
deciding that Core Data won't work here.
sorry, I certainly wasn't suggesting I discard CoreData. I was
thinking more that it should be possible to use the standard cocoa
keyarchiving stuff to create a type of property that coredata _could_
deserialise quickly.
an alternative to that would maybe be using coredata to store copies of
all the attributes I filter on in the arrangeObject in a single
NSData/binary field ....at least that would mean I would only need to
deserialise one property to do all the filtering.
Apple has done a ton of work with Core Data. It's not perfect, but
they have a lot of experience in data persistence and I believe many
(if not most) issues people run into can be resolved with just a bit
of patience and research. I especially say this because Core Data will
continue to improve in subsequent OS releases and you can get all of
that for free if you don't give up too easily.
absolutely agree. I seriously love coredata, its reduced the code in my
project by about a third.
In addition to the suggestion above, you might look into batch
faulting. This document appears to discuss issues very much related to
what you're doing:
I did try this, but in this case it seemed to make no discernable
different.
the thing is the properties Im fetching for the filtering aren't
faulted properties, they are standard NSDate or NSNumber objects.
thanks for your reply. I guess Ill have a try at getting the
NSArrayController setup to use a full predicate. Im not sure I have a
lot of hope though since at some point it _is_ going to have to
deserialise the properties (assuming that is what the actual slowdown
is).
does anyone have an idea as too what could be causing the slowdown, is
it reasonable to assume the problem is the deserialisation?
Yours cheerfully,
Andrew Bush
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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