dinsdag 27 december 2011

Memory profiling a Silverlight Application

It’s the nightmare of most developers:  a memory leak.  Not knowing which pesky reference is holding that object in its grip or what eventhandler refuses to let go of that viewmodel.  Today I’ve had the tremendous joy (notice the sarcasm please) of solving a memory leak.  To make matters even worse, the memory leak was caused by a Silverlight application.  I’ve seen a couple of suggestions for memory profiling a Silverlight application like Davy Brion’s solution, or even tried out a couple of memory and performance profilers like the one of Jetbrains, but none that felt comfortably to work with and looked too complicated for such a simple issue.

Then after I was just about to give up, I came across RedGates ANTS memory profiler.  At first I was skeptic because it seemed like a sales person wrote the introduction page of the tool but I was pretty desperate so I filled in my personal data and downloaded the trial.  Beware though cause RedGate actually uses your data to call you later on to get feedback and to try to talk you into buying their products.

The installation was easy and straightforward and after restarting visual studio I saw the ANTS submenu appear in the menu bar.  It didn’t take me much longer after that to find the memory leak.
The actual memory leaked wasn’t mine but was introduced by a class I found on the internet, the bindinghelper http://www.scottlogic.co.uk/blog/colin/2009/02/relativesource-binding-in-silverlight/ ).  The class helps a Siverlight developer to relatively bind to a property outside a datatemplate or whatever.  

Let me explain how I found the memory leak:

At first I launched the ANT memory profiler by clicking ANTS => Profile Memory.  It then started profiling my webpage by default so I stopped profiling and then clicked File => New Profiling Session.  It then launched to following screen:

I switched the Application Type to profile to Silverlight 4 and filled in the Silverlight Application URL.  After that I clicked Start Profiling.  

After some profiling it was very obvious I was dealing with a memory leak here:

So I then took a memory snapshot:

So now what is causing this dammed memory leak?   I then clicked the Class List button which gave me a list of classes and how many instances there were and how much memory it consumed.  

I then clicked the Instance Categorizer to see the dependency graph that references all these strings.  On the far left of the screen I saw the cause of all my troubles :-).

I immediately opened the BindingHelper class and saw that objects added to its dictionary weren’t removed when they weren’t needed anymore so it was just a matter of adding the right line and voila! Memory leak solved ;-)

From this I can draw two conclusions:

The first is never to trust code coming from the internet.  Allot of bloggers submit code that hasn’t been tested on the long run and is merely intended as a reference and not as a solution.

The second is that RedGates ANTS memory profiler is one sweeeeet profiler.  You don’t have to be a rocket scientist to use it and it show some nice graphs, and admit it, who can say no to pretty graphs and diagrams. 

Till next time!

Geen opmerkingen:

Een reactie plaatsen