I have a NSTreeController displayed via an NSOutlineView. It’s set up to expand items by default as they’re added to the model. This is all on Snow Leopard.
When a bunch of items (some thousands) are added and removed from the model, there’s a large memory spike (multi-hundred MB) almost entirely of Malloc 16.50 KB blocks, and the bulk of the CPU time is being spent in libauto. The stack trace of most of the memory allocations is: ... 12 libSystem.B.dylib _dispatch_call_block_and_release 11 libauto.dylib auto_collection_work(Auto::Zone*) 10 libauto.dylib auto_collect_internal(Auto::Zone*, unsigned int) 9 libauto.dylib Auto::Zone::collect(bool, void*, unsigned long long*) 8 libauto.dylib weak_call_callbacks 7 Foundation NSKeyValueObservanceBecameUseless 6 Foundation _NSKeyValueRemoveUselessObservances 5 Foundation _NSKeyValueObservationInfoCreateByCollecting 4 Foundation -[NSKeyValueObservationInfo _initWithObservances:count:] 3 Foundation -[NSConcretePointerArray addPointer:] 2 libauto.dylib auto_assign_weak_reference 1 libauto.dylib weak_register 0 libauto.dylib append_referrer_no_lock(weak_referrer_array_t*, void**, auto_weak_callback_block*) Almost all of the rest are: ... 21 MyProject -[MyModelObject addChild:] 20 Foundation NSKVOInsertObjectAtIndexAndNotify 19 Foundation -[NSObject(NSKeyValueObserverNotification) didChange:valuesAtIndexes:forKey:] 18 Foundation NSKeyValueDidChange 17 AppKit -[NSTreeControllerTreeNode observeValueForKeyPath:ofObject:change:context:] 16 AppKit -[NSTreeControllerTreeNode updateChildNodesForKeyPath:affectedIndexPaths:] 15 AppKit -[NSTreeControllerTreeNode updateChildNodesForKeyPath:affectedIndexPaths:] 14 Foundation -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] 13 Foundation NSKeyValueDidChange 12 Foundation -[NSKeyValueNestedProperty object:withObservance:didChangeValueForKeyOrKeys:recurse:forwardingValues:] 11 Foundation -[NSObject(NSKeyValueObserverRegistration) addObserver:forKeyPath:options:context:] 10 Foundation -[NSObject(NSKeyValueObserverRegistration) _addObserver:forProperty:options:context:] 9 Foundation -[NSKeyValueUnnestedProperty object:didAddObservance:recurse:] 8 Foundation -[NSKeyValueNestedProperty object:didAddObservance:recurse:] 7 Foundation -[NSObject(NSKeyValueObserverRegistration) addObserver:forKeyPath:options:context:] 6 Foundation -[NSObject(NSKeyValueObserverRegistration) _addObserver:forProperty:options:context:] 5 Foundation _NSKeyValueObservationInfoCreateByAdding 4 Foundation -[NSKeyValueObservationInfo _initWithObservances:count:] 3 Foundation -[NSConcretePointerArray addPointer:] 2 libauto.dylib auto_assign_weak_reference 1 libauto.dylib weak_register 0 libauto.dylib append_referrer_no_lock(weak_referrer_array_t*, void**, auto_weak_callback_block*) After every item is eventually removed (aside from one remaining one in the root, which was already there at the start), the app is still using 48MB RPRVT. This was 6MB at the start of the process, in this same model state as it ended. heap -guessNonObjects shows most of the memory as non-objects in dictionaries and arrays (e.g. NSCFDictionary[48]), and NSConcretePointerArrays, all in the auto zone. The only references to some of these key function names I could find on the web were in the libauto sources, and no mention at all in mailing lists, so it doesn’t seem like anybody else has posted about this before. Any ideas about why NSTreeController’s KVO is taking up so much memory/CPU with bookkeeping? Any suggestions for working around the problem? Thanks, Benjamin Rister_______________________________________________ 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
