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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
