Deep size

Gibson · Post by **Gibson** » Thu Aug 18, 2005 3:01 pm

OK, I know deep size isn't retained size and I know that retained size is the most useful for finding memory leaks.

But I am currently engaged in reducing the overall memory usage of our application and in this case I think that "deep size" can be useful. For example, I have a class with 100 instances which use 100M between them. I wonder where the memory is used, so I open the node. None of the fields show more than a few 100k, so obviously some of the fields are sharing references to some "heavy" objects. But which ones? And which objects? I have to guess ... but if I had a "deep" object size I could work out a plan of attack.

What do you think? It should be easy to calculate this at the same time as you calculate the retained size.

Post by **Anton Katilin** » Fri Aug 19, 2005 1:33 pm

Hi,

Could you please describe in more detail what you mean with "deep size"?

I would recommend using "Biggest objects". Also, the upcoming build 640 (will be ready in several hours) will have action "View Retained Set", that e.g. can be applied to the "Class Tree"'s node and then examined with "Biggest objects".

Best regards,
Anton

Gibson · Post by **Gibson** » Mon Aug 22, 2005 12:45 pm

"Deep size" is the size of all the objects that are reachable from the current object. These objects might not necessarily be retained by the current object, as they might be also referenced from elsewhere.

My point was that when we are trying to generally reduce memory consumption, rather than find memory leaks, this size might be relevant?

Anyway, I have downloaded build 640 and will have a play with it.