Re: Core Data fetch performance
Re: Core Data fetch performance
- Subject: Re: Core Data fetch performance
- From: Rick Mann <email@hidden>
- Date: Sun, 11 Nov 2012 16:16:34 -0800
On Nov 11, 2012, at 15:54 , Hunter Hillegas <email@hidden> wrote:
> Heh, I re-read your post like four times and only just now saw that notation. Whoops.
It happens.
>> Can one build IN queries directly?
>
> I'm not entirely sure I know what you mean by 'directly' in this context.
Instead of using -predicateWithFormat:, creating an NSComparisonPredicate, perhaps type NSInPredicateOperatorType, and pass an array of NSNumbers to it. Not sure that's how it works.
>> I currently download on a separate thread, then call back to the main thread for each record. The intent was avoid doing Core Data work on a separate thread, and keep the UI responsive. But that doesn't really enable the second core, and it adds a lot of overhead. Maybe it's time to do the Core Data on the second thread, too. Pretty sure that will require substantial changes to the way my UI keeps up with updates.
>
> GCD, along with the Core Data changes in iOS 5 and 6 for handling concurrency, make this much easier than it used to be (or at least cleaner and harder to screw up as badly).
I'll have to look into it. I also need my UI to populate as the loads are happening, at least partly, which means no longer doing one big UI update at the end of the operation.
Thanks,
--
Rick
_______________________________________________
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