CoreData/NSManagedObject accessor performance problems
CoreData/NSManagedObject accessor performance problems
- Subject: CoreData/NSManagedObject accessor performance problems
- From: Andrew Bush <email@hidden>
- Date: Sun, 17 Dec 2006 01:37:33 +1300
Hi all,
Im displaying a few thousand (3 thousand so far, but its going to get a
heap larger) records in an NSTableView, via a binding to an
NSArrayControllers contentSet.
That NSArrayControllers contentSet is bound to another
NSArrayControllers selection.
it all works wonderfully, and is remarkably quick.
The interesting stuff seems to happen when I try to filter the content
before displaying it in the tableview.
first I attempted this by adding a predicate to the NSArrayController,
but it appears to ignore the predicate when it is bound?
so anyway, now I have sub-classed the NSArrayController that the
tableview is bound to, and Im overriding arrangeObjects to filter out
the ones I dont want.
contrary to my expectations, using an enumerator to iterate through
3000 the or so objects takes pretty much no time at all. yay!
unfortunately I have found that simply accessing data on a single one
of the objects during the iteration increases the time taken to around
6 seconds, this is without actually doing any comparisons, just calling
id somevalue=[object valueForKeyPath:@"keypath"] slows the loading of
the data by that much.
the type of the data being accessed seems pretty much irrelevant,
accessing a NSDate, an NSNumber or an NSString all means that the loop
goes from being pretty instant to taking around 6 seconds.
if I add all the filtering I require the whole thing takes around 12
seconds to load, which is obviously (a) way too slow and (b) going to
become _really_ slow once I have a few more thousand records.
its partly so frustrating because everything I thought _might_ take
time, the loading and the looping, is so damn quick :)
Ive tried creating a predicate to filter the object array by a single
value, and that takes around the same time as doing the equivalent task
with an enumerator..I assume both approaches are doing pretty much the
exact same thing.
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.
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, consisting of pretty much nothing at
all, so that I can store raw numbers and data and access them without
the deserialisation overhead.
but, before I begin.....does anyone else have any ideas on the possible
causes? on alternate (simpler) solutions?
<g> ..or even any good examples/documentation simple keyarchiving
schemes?
thanks for any help.
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