Profiling Memory Usage Using The Visual Studio 2010 Profiling Tools

I don't want you to get the impression that I only work with SQL Server developer.  This post is related to profiling memory usage using the Visual Studio 2010 Profiling Tools (which is only available with the Premium and Ultimate editions).

Yesterday, for the first time, I used the Visual Studio 2010 along with the Performance Wizard.  I need to determine why our app is consuming so much memory.  I must either produce a plan for fixing the problem or provide an explanation why the memory consumption is valid.  Our app intensively uses images and user controls, along with third party "image processing" user controls.  I am using the ".Net Memory Allocation (Sampling)" profiling method.

See MSDN: Analyzing Application Performance by Using Profiling Tools.

The Performance Wizard is used to prepare a new Profiling Session.  All of the configured Profiling Sessions are listed within the Visual Studio Performance Explorer (View menu -> Other Windows -> Performance Explorer).  There, you can right-click on the Profiling Session to adjust more settings.  One such setting for .NET memory profiling is "Also collect .NET object lifetime information".

See MSDN: Collecting .NET Memory Allocation and Lifetime Data.

My initial experience with the Profiler was mixed.  On the one hand, I have never had so much detailed memory usage at my fingertips.  On the other hand, I really want to know 1) how much memory is being allocated, 2) how much memory is being deallocated, and 3) how much memory is still consumed when work is done. Finding the "Also collect .NET object lifetime information" setting was important.

The scope of what is profiled is important.  I profiled a large portion of the application in one profile session.  This produced a huge file, with a very high "signal-to-noise" ratio.  It is better to focus on a small portion of the application's operation in order to get actionable metrics.