re: Core Data faulting and bindings: recursive KVO notifications?
re: Core Data faulting and bindings: recursive KVO notifications?
- Subject: re: Core Data faulting and bindings: recursive KVO notifications?
- From: Ben Trumbull <email@hidden>
- Date: Fri, 28 Mar 2008 12:24:00 -0700
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 (email@hidden)
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:
This email sent to email@hidden