A View from the Top
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. Read more: Silverlight Performance Blog
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. Read more: Silverlight Performance Blog
Posts
0 comments:
Post a Comment