Does the performance of saving a ManagedObjectContext depend on the number of contained (unchanged) objects?

A general CoreData/SQLite question

Is there a significant difference between these two scenarios when saving a NSManagedObjectContext using an SQLite store:

• After adding/changing/deleting one object in a NSManagedObjectContext containing 10 otherwise unchanged NSManagedObjects
• After adding/cha开发者_运维知识库nging/deleting one object in a NSManagedObjectContext containing 10'000 otherwise unchanged NSManagedObjects

Generalizing from my experience with Enterprise Objects (which Core Data evolved from) I would say that both of your scenarios would be equally fast without indexing and the second slightly slower with indexing.

Using and SQL store, the cost of adding one object is largely fixed regardless of how many other objects are in the graph. Indexing does cause a scaling effect because the index is dependent on other existing objects. However, in the vast majority of cases, this is not significant.

The more complex the relationships within the graph the more saves are impacted by total graph size. Obviously, if you have graph with only ten objects, then no relationship can have more than ten objects in it. If you have one with 10,000, the relationships are potentially much larger and take longer to process.

In sum, Core Data with an SQL store appears to be largely unaffected by just the size of the graph.

Profiling will tell you if there's a significant difference. However, I suspect that the type of the store coordinator will affect the performances. Updating an object in a SQLite database is probably faster and more scalable than doing so in a XML tree.

In my previous experience there is not a significant difference. If the object being added/changed/deleted contains a lot of indexed attributes, then it will take just slightly more when compared to the case of an object with no indexed attributes, but this is expected since indexes will also be modified as well.