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: Mon, 18 Dec 2006 09:48:19 +1300
Hi Scott,
A filter predicate should work, but not a fetch predicate.
heh. right. I just recently noticed there wsa a difference, Ill try
it out sometime today.
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.
I think that should work, assuming the understanding of the
performance problem area is correct. :)
I do wonder if there is some way of accessing the raw data without all
that mucking about. Im going to play with a sqllite client today and
see what coredata is actually storing..I find it hard to believe that
it is really storing the entire serialisation of a NSNumber (for
instance) in the database.....if they are it must play hell with the
speed of the queries.
If Im right and they dont, then somewhere, somehow, it must be possible
to gain direct access to the values stored before the serialisation
takes...you wouldn't want to do that in most cases, or carelessly, but
it must be possible and I think in this specific case it would be kind
of worthwhile....all I really want to do is compare a double against a
double...
does anyone know if there is some way of gaining direct access to the
underlying data from an NSManagedObject?
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