How often should I save to Core Data?

I'm working on an application backed by Core Data. Right now, I'm saving the Object Context as and when I add or delete an entity to and from the Context. I'm afraid it will affect the performance, so I was thinking of delaying the save. In fact, I could delay it all the way until the application is gonna terminate. Is it too risky to save the data only when the application is about to close? How often should I call the save on Object Context?

I was thinking of having a separate thread handle the save: it will wait on a semaphore. Every time any part of the application calls a helper/util method to save the Core Data, it will decrement the semaphore. When it is down to zero, the "save thread" will do a save once and it increments the semaphore to a, say, 5, and开发者_如何学JAVA then sleep again.

Any good recommendation? Thanks!

---

You should save frequently. The actual performance of the save operation has a lot to do with which persistent store type you're using. Since binary and XML stores are atomic, they need to be completely rewritten to disk on every save. As your object graph grows, this can really slow down your application. The SQLite store, on the other hand, is much easier to write to incrementally. So, while there will be some stuff that gets written above and beyond the objects you're saving, the overhead is much lower than with the atomic store types. Saves affecting only a few objects will always be fast, regardless of overall object graph size.

That said, if you're importing data in a loop, say, I would wait until the end of the complete operation to save rather than saving on each iteration. Your primary goal should be to prevent data loss. (I have found that users don't care for that very much!) Performance should be a close second. You may have to do some work to balance the frequency of saving against performance, but the solution you outline above seems like overkill unless you've identified a specific and significant performance issue.

---

One issue not mentioned here in other answers is that your solution, which involves using a background thread, should not be operating on a managed object context used in another thread. Generally you make a new MOC for background threads, but that would defeat the purpose of saving if you saved to a different/unmodified background MOC.

So a few answers to your question:

1. You would need to call back your original thread to save the MOC
2. As the current accepted answers suggests the whole counter might be overkill for your needs unless a performance issue was measured.
3. If a performance issue WAS measured, you could take a simple throttling technique where you set a limit of, say, 1 save per 10 seconds. Store the Date of the last time you saved. When your save function is called always make sure the current time is > 10 seconds since your last save otherwise, early return.

You really want to be saving immediately as much as possible, so at the very least my recommendation is to throttle rather than arbitrarily set any timer or countdown.

---

The best way I think, is to save after every object. If something ever happens such as a sudden crash nothing will be lost.

Some performance enhancements, if you adding a lot of objects is to batch. Add all objects to the context than save. This is good for example if you adding a lot objects in a loop. Your idea is similar, but there could be a long time between saves, in which the program could crash.

I don't think adding a single object would be a that much of a performance problem. How big are your objects, do they contain a lot of data?