InquisitorJax wrote:When analysing the memory usage, the sum of the class list doesn't seem to add up to the private working set. Is it meant to?
No: the totals for the class list will only add up to the total amount of memory used by live object instances. 'Private working set' could actually be less than this due to the way Windows manages working sets. 'Private bytes' will always be more, as in any .NET program the CLR itself will use some unmanaged memory, and .NET always allocates some memory to create new objects in.
And if not - where is all the memory allocated that is not displayed?
It will mostly be accounted for by unmanaged memory and memory that .NET has reserved but is not using yet. As you're profiling Silverlight, the memory used by Internet Explorer to display the page your application is on will account for a fair proportion of that space.
The summary page gives an indication of how much free memory .NET has reserved but isn't using yet. You can also see this broken down by generation in the session overview tab.
Also - the big indicator seems to me to be the column "Size with Children" on the instance list. It would be nice if this was more readily available in the summary page.
Size with children is expensive to calculate, so this would be impractical for large applications. Additionally, it's calculated by simplifying the memory graph into a tree, which means it often won't reflect how the target application is working internally. The total value will add up to much more than the total memory being used by an application as objects will be referenced from more than one location.
The class graph is designed to show how these relationships break down and help find what is referencing the most memory: if you start with a class using a lot of memory, you can use the graph to trace back from there to instances which will have a high 'size with children' value.