[gurkendoktor]

> A large save will easily reach into >200ms land on an iOS device, and your app will feel like crap.

Can you give an order of magnitude at this would happen? I usually only have 50-200 entities in my database in total, saving maybe half of them at the same time. Yet libraries like RestKit insist on a two-context setup to avoid the saving delay you mention. I'm not sure if I should fight the libraries and go back to a single-threaded setup (that I understand) or just go with the parent/child context flow.

[delackner]

Fetch and save operations get pretty slow with even just 10,000 entities (if you touch all those entities). It gets a little better if you pre-fetch all the entities rather than one at a time, but the save is still very slow. Breaking that out into a backround thread is feasible, but as the previous commenter mentions, then you risk momentary divergence between the UI and the backend.

[seivan]

Index properly. Save in a queue.

[delackner]

This is fetching every entity by its indexed key. My understanding of saving in a background queue is that during that 1-2 seconds, the ui will still be using the pre-modification data set, so very briefly the ui may appear incorrect, no? Not a huge deal, but if the ui will be wrong, then for our app that would still force us to pause the ui until the save finishes.