Re: Core Data fetch performance
Re: Core Data fetch performance
- Subject: Re: Core Data fetch performance
- From: Hunter Hillegas <email@hidden>
- Date: Sun, 11 Nov 2012 15:54:40 -0800
>> Do you have keyShadow set as indexed in the model? If not, you probably want to give that a try.
>
> Yeah, the key is indexed (as I pointed out in the original post :-))
Heh, I re-read your post like four times and only just now saw that notation. Whoops.
>> If you have all of the keys up front (i.e. this is a big batch update or insert from the Web Service data), you might consider loading all of the records at once and then using a predicate to find what you need. Something like:
>
> I do. I was thinking about this last night. I'm concerned that this may require too much memory, and building a string of 6400 IDs for the query to then format...sounds expensive.
It's possible that doing them all in one hit might be too much… As with most workloads, you may need to experiment to find a happy medium.
> Can one build IN queries directly?
I'm not entirely sure I know what you mean by 'directly' in this context.
> 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).
_______________________________________________
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