locked
Memory Management strategies in Silverlight RRS feed

  • Question

  • So, it looks like we are leaking.  We are leaking like crazy.  Here is why:

     We have user controls that are being dynamically added and removed to/from the Children collection of other user controls.  These user controls hook event handlers on objects with longer lifetime than the controls, so we are leaking the controls.  This is a well known case of memory leaks within .NET.

    To solve this, I can use the classic approach:  Implement IDisposable, unhook events in the Dispose() and call it after it is removed from the children collection.  I can say from expriernce that this gets messy quickly.

     I would prefer to override something on the UserControl such as OnRemovalFromParent() but there no such thing.

     How do you handle this issue?  Is there a cleaner way to handle this than "Dispose"?  What do you think?

    Brian

    Thursday, February 12, 2009 3:04 PM

All replies

  • Hi,

    These user controls hook event handlers on objects with longer lifetime than the controls, so we are leaking the controls.  This is a well known case of memory leaks within .NET.

    Could you give me a sample of this? I believe this is not a good programming habit that we can avoid. One possibility is that you probably maintain the reference of the Page in your UserControl and hook the Page's event in your UserControl. In this case you can use Dispose() method to explicitly unhook it.

    About event handler and memory leak, the typical issue is mentioned in the following article (is it the same issue as you mentioned?):

    http://blogs.msdn.com/tess/archive/2006/01/23/net-memory-leak-case-study-the-event-handlers-that-made-the-memory-baloon.aspx

    By exposing event from UserControl and hook it on the page will not leak memory, as far as I know.

    Sunday, February 15, 2009 11:08 PM
  • Yeah, that is the leak that I am referring to... an observable that lives longer than the observer will keep the observer alive as long as the event is hooked (or the observable goes away).  If the only reference left to the observer is in the observable, then you have leaked, because the observable can't know to remove the observer.  It is, in my experience, the most common type of memory leak in .Net.

     So, an example of such leak in Silverlight?  Lets say, for the purposes of example, you have an application that displays many video clips.  These videos can be added or removed by the user dynamically.  On the root Page, there is a toolbar that controls these images, and they all play/stop at the same time.  The video player user controls are added dynamically to their parent's children list and they hook up to the root Page's play/pause events.  They are then removed from the children list the same way.  If the user controls don't release their event handlers, they will leak.

     It's not that I don't know how to solve this problem... I do:  You make the user control implement IDisposable and you call Dispose() after it is removed from the children list.  In the Dispose() method, you unhook your handlers, and the leak is avoided.  Unfortunately, I find this kind of code to be extremely error prone and ugly.  I am wondering if there is a better pattern that I can use to make the code less kludgy...

     Any thoughts?

     

    Monday, February 16, 2009 7:43 AM
  • Hi,

    So, an example of such leak in Silverlight?  Lets say, for the purposes of example, you have an application that displays many video clips.  These videos can be added or removed by the user dynamically.  On the root Page, there is a toolbar that controls these images, and they all play/stop at the same time.  The video player user controls are added dynamically to their parent's children list and they hook up to the root Page's play/pause events.  They are then removed from the children list the same way.  If the user controls don't release their event handlers, they will leak.

    Could you provide sample code for this scenario? It would be better for us to discuss based on some code..

    Monday, February 16, 2009 8:44 PM