The problem I'm having arises when selecting all images at once (Command+A), if they are fairly large in number (in my store: ~2000). This takes an enormous time that is definitely > O(n).
Command-A should be instantaneous, even for selections 10x larger. The typical performance problems I've seen with array controller selections are (1) complex KVO observer actions cascade (2) tripping faults unnecessarily (3) using expensive array controller options.
(1) Complex KVO observer actions need to be carefully constrained. If they simply grow organically, then it's pretty easy to fall into the trap of observers creating side effects that trigger other observers that cascade to yet more observers. This (a) makes your code impossible to understand, since no one ever intentionally designed their app that way from the beginning, and (b) sucks for performance.
It's often easier to understand, and much faster, to use NSNotificationCenter to defer and coalesce observations for a batch operation like operating upon 2000 objects. One way to achieve this with the array controller is to remove all the objects from the controller, do your batch operation, and then add them back.
(2) Firing faults unnecessarily is the canonical performance issue for Core Data developers. Our SQL logging (-com.apple.CoreData.SyntaxColoredLogging 1 -com.apple.CoreData.SQLDebug 1) and our Instruments template can help you find this, and identify which entities you're faulting excessively.
If you need that data, it's much (10-100x) better to batch fetch the data instead. This is described in the Core Data Programming Guide under Performance.
(3) Auto rearrange content can be very expensive. It can make the notification cascading from (1) worse. Also, Avoid empty selection & Preserve selection can force the array controller to fire faults it otherwise wouldn't, which is expensive.
Regarding the call into _didChangeValuesForKeys:, the API contract for KVO requires Core Data call -willChange/-didChange during faulting. This is pretty undesirable.
This recurses further with all images in the controller selection until the whole object graph is in-memory. It is much slower (>1 minute on a MBP with 2000 elements in the controller set) than loading the data in a normal manner, probably because of spread faulting and the large stack depth.
If it's actually recursing through the entire graph, then it's probably a bug in your observer method. If it's looping, then it could simply be toggling off a few array controller options will address the issue.
You should file a bug with bugreport.apple.com, and include the entire stack trace. Without the rest of it, it's hard for me to say if this is the expected stack depth or not. It may be a problem with one of your custom observation methods not coexisting happily with faulting, but it's a bit hard to tell from this excerpt.
-- -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 [EMAIL PROTECTED]
