Re: Memory not being released in a timely manner
Re: Memory not being released in a timely manner
- Subject: Re: Memory not being released in a timely manner
- From: Jonathan Taylor <email@hidden>
- Date: Mon, 10 Jun 2013 16:23:05 +0100
Thanks for your comments Ken. It was really good to learn about how to use heapshots effectively, that's definitely something I'm going to use again in future. In this case it did provide ~some~ more information on what is going on.
Just to be clear, the problem is now solved by wrapping the correct bit of code in an explicit autorelease pool, but I'm still very interested in understanding what's going on and why Allocations is not reporting large chunks of memory - I still maintain that this is not happening. If I understood your reply correctly, you're saying this isn't what you would expect. The following results are with the explicit autorelease pool (bug fix for my issue) disabled so that the problem manifests itself.
With the use of heapshots, it does turn out there are in fact ~small~ objects accumulating that are reported by Allocations. An example screenshot can be viewed here:
https://docs.google.com/file/d/0Bye8FKbpg3dYRWF0YWo1djNmZVU/edit?usp=sharing
However this is only reporting relatively small amounts of memory still outstanding from during the image processing run. The fact that there are Image/Bitmap objects in there should ring alarm bells, and watching one of those objects would have given me a very strong clue as to what was going wrong, had I done it earlier. For example:
https://docs.google.com/file/d/0Bye8FKbpg3dYcnlQRWt0ZDlVdjA/edit?usp=sharing
is pretty strong evidence that it's a delay in autorelease pool drain that is causing all this memory to sit around.
However, if I understand you correctly, you are convinced that the (large) backing buffer for the bitmap data should be being reported by Allocations. As you can hopefully see from these screenshots, while the NS objects themselves are being reported as live, the backing memory itself really doesn't seem to be showing up in Allocations (though the VM tracker knows about it. When you wrote:
> So, the Allocations instrument should have been showing you those living objects. True, it couldn't show you the size of memory ultimately dependent on those objects, but that's often the case (i.e. a small object that owns a large NSData or something; Allocations would sort the NSData to the top but you'd have to hunt to find the small object that owns it).
... it seems that my observations match that in terms of the top-level objects, but there really doesn't seem to be any sign at all of the backing memory. Weird.
Cheers
Jonny
_______________________________________________
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