On 6 Jul 2009, at 23:37, Devraj Mukherjee wrote:
Thanks all for your feedback. Seems quite inefficient. Wonder if this
is filed as a suggestion to Apple.
Seeming and being aren't the same. If you encounter performance
issues with Core Data, please capture a Shark or Instruments trace and
file a radar.
There are two reasons to have a batch API generally: convenience and
performance. If after all this time there is still no batch deletion
API for Core Data, it is almost certainly because no-one has found it
to be a performance bottleneck that could be improved by a batch API.
Consider the work required by a deletion:
- Validate the object for deletion
- Internally mark the object as as deleted internally
- Any applicable relationships cascaded or nullified
- Add to the undo stack
Would a batch API really be significantly faster than iterating the
objects yourself? (disclaimer: I don't know)
If they are properly prefetched, then generally no.
Most people who have requested this for performance don't want to
actually have the objects at all. Something more like "delete all the
objects in the store that match this predicate", perhaps -
deleteObjectsMatchingFetchRequest:error: . Unfortunately, that
creates something of a conundrum. How would we notify KVO observers,
undo, use custom setters, or make any delegate callbacks for the
deleted rows which were never materialized into objects ? I don't
think we can, and we don't have a satisfactory resolution to this.
The performance gains are pretty modest anyway, so it's not clear it
would be worth the effort.
Particularly since those
changes are all in-memory; deleting objects from the persistent store
only happens upon a -save: which is effectively a batch operation of
itself.
That's spot on. The -save: operation is a batch, a complete
transaction in itself, and the single largest cost is the transaction
cost and db I/O. You can control the scope of the transaction by
saving more or less frequently, or creating additional separate MOCs.
As ever, the golden rule: Write the easiest code you can first. If it
turns out to be a performance issue, profile it and figure out why. If
the bottleneck really isn't one you can fix, rework the design and
file a bug report.
- Ben
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
