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 15:32:02 -0800
On Nov 11, 2012, at 9:57 , Hunter Hillegas <email@hidden> wrote:
> 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 :-))
> 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. Can one build IN queries directly?
I could do it in small batches. In truth, there will generally be more new records than updated records, and by adding a created-date (I currently use a last-modified-date), I can determine if the record is new or updated. Then I can skip the fetch for most of the downloaded records. But that's such a big change.
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.
--
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