Re: Search Kit memory management
Re: Search Kit memory management
- Subject: Re: Search Kit memory management
- From: Ken Thomases <email@hidden>
- Date: Sun, 1 Aug 2010 11:44:42 -0500
On Aug 1, 2010, at 11:10 AM, Michael Thon wrote:
> I should probably just stick to my observations and state that "Real Mem" in Activity Monitor is reduced by several hundred MB when the NSOperation finishes indexing a few thousand documents.
Yeah, using "Real Mem" in Activity Monitor is a bit iffy. If you see it going up, then that's generally a real occasion of your app using more memory. However, if it stays up, that is not necessarily an indication that your app's memory use is staying high. The memory allocator may keep memory that your code has released for quickly satisfying a future request, rather than returning it to the system.
>> I reiterate my suggestion to use the Object Allocations instrument, configured to record reference counts, to investigate. Even if you investigate your current solution, it will illuminate why and when the objects are released, which can help you understand why it seems to fix the issue and lead to a better fix.
>>
> I did check the retain counts in Instruments and I see that there are sometimes more than 1000 SKDocument objects with a retain count of 1, even though my code creates these objects and releases them one at a time. In Instruments I cannot see who has actually retained these objects, but I will consult the documentation to see where this info is hidden. At the time, I concluded that they must be retained by Search Kit, which was out of my control anyway, so I abandoned this line of investigation.
Before you record, you configure the Allocations instrument by clicking the little 'i' icon to the right of its name. In the window that pops up, enable "Record reference counts".
Then, once you have recorded data from your app, you need to dig into the details of one specific SKDocument object in the details view. Click the right-arrow icon that appears next to the category name to see the specific instances. Click the right-arrow icon next to a particular object address to see the history of retains, releases, and autoreleases. From the View menu, make sure the Extended Details section is visible. Select a particular event to see the stack trace of when/where it happened.
Note that this doesn't quite directly answer "which code is responsible for this object still being alive". You have to manually match up retains to releases to figure that out, with autoreleases making that extra complicated because the actual release happens later and is attributed to the code which drains the pool, not the code which autoreleased the object. It's possible to figure it out, but you have to wade through the data.
> The comments by Aaron make me think that perhaps I should not be so concerned about the memory usage reported by Activity Monitor (and that I'd better understand how it reports memory in the first place). When I watch object allocations in Instruments, I see that the total number of living objects (# living for the All Allocations row) oscillates between a maximum number and minimum number and this is reflected in the graph. After a minute or so the oscillations appear to even out and the number # living tend to stabilize and even slowly decreases over the next few minutes. The memory listed in the Live Bytes column is much lower than that reported by Activity Monitor and reflects exactly what I see in # living objects. Memory usage in the Live Bytes column stabilizes at less than 100 MB. My application seems to be indexing documents at a more or less constant rate. All the while Activity Monitor reports that my application is using more and more "Real Mem" .
>
> My interpretation is that the memory usage of my application is fine, according to Instruments. I don't know if it is safe to ignore what Activity Monitory reports though. I will find some more documentation and try to figure out what it is telling me.
I agree that this sounds like your app is probably doing the right thing. There are forms of memory allocation which the Allocations instrument doesn't track: mmap and vm_allocate. It is quite possible that Search Kit is using one of those to maintain its index contents. If so, then there is probably no need to worry about it unless and until the growth starts to interfere with the operation of your app and/or the system. Even then, your main recourse would be to index less data or switch to some other technology to do the indexing.
Cheers,
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