On Dec 8, 2009, at 2:44 PM, jonat...@mugginsoft.com wrote: >> Any ideas about why NSTreeController’s KVO is taking up so much memory/CPU >> with bookkeeping? Any suggestions for working around the problem? >> > I assume that you are using bindings.
Yes. > Looks like a typical KVO notification storm to me. > What works well for adding and updating one or two objects can easily turn to > sludge for larger object numbers as thousands of KVO notifications are sent. > This isn't bookkeeping - its KVO doing what you asked it to do - telling you > about every change to your model. Well...not quite. There’s nothing about doing this notification that requires allocating hundreds of megabytes of overhead, particularly when the model itself is a fraction of that size, including payload. As I mentioned, these blocks it’s allocating are 16KB each. I can’t fathom what legitimate data you could possibly keep to do this observation that would take up that much space. In addition, if you look at the stack trace, most of the memory allocations are happening in response to NSKeyValueObservanceBecameUseless; thus, it’s happening after all of the actual, real work is done. It’s entirely speculation, but this could be explained by transient KVO stuff not being garbage collected properly, like it’s being kept alive unnecessarily. Also, while I forgot to mention this in the original email, the allocations follow a sawtooth pattern with a period of around 1-2 minutes, rising steadily then suddenly vanishing in an instant. This could support the GC hypothesis, or just be a red herring. Maybe these allocations are being missed by the generational collector for some reason, and are only caught by exhaustive collections? Or maybe some structure/cache/buffer is being periodically flushed, dropping the references? The model objects are gone (obviously, since that’s what triggers the allocations), so it shouldn’t be me keeping them alive. > Are you adding your nodes to the NSTreeControllers content while bindings are > active? > If you build your tree separately and then set the NSTreeController > content/binding then things should improve drastically. Unfortunately, this isn’t static content. It’s dynamic, and needs to change in response to external conditions. So the KVO notifications themselves are necessary in this approach, the overhead just seems unreasonable. Best, Benjamin_______________________________________________ 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
