So you’ve decided that it’s time to optimize the memory footprint of your Silverlight application. Before you’ll be able to do this analysis and optimization, you’ll need to understand a little bit about the way that Silverlight is structured.
Though the Silverlight programming model that you’ve come to know and love is accessed via managed code, much of Silverlight’s internals are written in native code (C++). The actions that you take in managed code can cause Silverlight to allocate large amounts of native memory on your behalf, be it for layout, rendering, image allocations, you name it.
Especially important to remember is that your managed Silverlight elements will have a native memory counterpart. Reducing the element count in your visual tree will have a direct and favorable impact in native working set. Because of these native allocations, this article will go over analyzing native memory in addition to managed memory.
Where to start?
One of the most intimidating parts of performing memory analysis can be deciding where to start. Often developers don’t focus on memory usage until it becomes a problem, at which point the project has already grown to a rather complex scale. The good news is that there is already a great free tool that can help you divide the problem into more manageable pieces, this tool is VMMap.
VMMap enables you to look inside your process to see both visual and statistical breakdowns of your working set. Once you’ve attached to your Silverlight application you should see three color-coded horizontal bar charts across the top of the window, where each color corresponds to the similarly colored category row in the grid below. You can click each of the column headers in the grid to sort the data in that dimension. Clicking the row for a particular category will filter the per-allocation view at the bottom of the window.
Read more: Silverlight Performance Blog