问题
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
NSManagedObjectContextcontaining 10 otherwise unchangedNSManagedObjects - After adding/changing/deleting one object in a
NSManagedObjectContextcontaining 10'000 otherwise unchangedNSManagedObjects
回答1:
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.
回答2:
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.
回答3:
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.
来源：https://stackoverflow.com/questions/2229690/does-the-performance-of-saving-a-managedobjectcontext-depend-on-the-number-of-co