Re: Removing Observers eats up memory
Re: Removing Observers eats up memory
- Subject: Re: Removing Observers eats up memory
- From: Ken Thomases <email@hidden>
- Date: Mon, 25 Jan 2016 13:23:37 -0600
On Jan 25, 2016, at 1:05 PM, Markus Spoettl <email@hidden> wrote:
>
> When I break in the debugger I end up in various different library functions concerned with hash tables and the like, such as
>
> #0 0x00007fff9ddc6d03 in weak_entry_for_referent(weak_table_t*, objc_object*) ()
> #1 0x00007fff9ddc84b6 in weak_read_no_lock ()
> #2 0x00007fff9ddc8473 in objc_loadWeakRetained ()
> #3 0x00007fff9ddc861f in objc_loadWeak ()
> #4 0x00007fff9cbc81c5 in hashProbe ()
> #5 0x00007fff9cbcbf3a in -[NSConcreteHashTable rehashAround:] ()
> #6 0x00007fff9cbc8245 in hashProbe ()
> #7 0x00007fff9cbc8014 in -[NSConcreteHashTable addObject:] ()
> #8 0x00007fff9cbf3f48 in _NSKeyValueObservationInfoCreateByRemoving ()
> #9 0x00007fff9cbf3933 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] ()
> #10 0x00007fff9cbf3837 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] ()
> #11 0x00000001002e71f2 in -[TrackEditorViewController unregisterObserverForDataPoint:] at /Users/markus/Projects/rubiTrack/src/TrackEditorViewController.m:639
This looks like manipulation of the side table I mentioned when you don't implement observationInfo. Of necessity, this side table is global, for all objects which don't implement observationInfo. So, adding and removing large numbers of objects seems like it sometimes triggers a reorganization of the hash table.
> Not sure which instrument would help me finding out what is going on. I was using the Time Profiler but it didn't really help, partly because it's really difficult to know if I'm hitting the bug or not (it doesn't happen every time).
Well, since you were seeing runaway memory allocation, I figured the Allocations instrument would be useful. It would show the spike in memory usage and what was responsible for the allocations.
>> By the way, you should consider implementing the observationInfo property on
>> your observed class. This avoids KVO storing observation info in a side
>> table. Note that the property is a void pointer, not an object pointer, and
>> therefore does no memory management.
>
> This is interesting. When I implement this property in the proxy object, the problem goes away (at least I wasn't able to duplicate it so far). Turn off the implementation, it comes back. Not really sure what this tells me, though.
Implementing the property avoids the need to use the global hash table to look up the observation info by the object's address. That, of course, sidesteps the whole issue of any performance issues with the hash table reorganizing itself. It's also just plain faster even without this specific issue with the hash table. The only thing you stand to lose is making your objects slightly larger. Since it sounds like these objects are basically guaranteed to be key-value observed, though, it ends up saving memory.
Regards,
Ken
_______________________________________________
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