locked
Hilarious memory issue with Silverlight RRS feed

  • Question

  • I hope this isn't a duplicate post, but it's hard to find the right search terms to look for this.

    Our company is testing our out-of-browser Silverlight 4 application, and were commenting on how the memory usage would continuously grow as they used the application.  Our app uses some very complex graphics, and whenever new stuff was rendered the memory usage would increase and stay increased.

    Here's the really strange thing: if you minimize the window, the memory usage, even if it's grown to a gigabyte worth, drops back down to the single-digit megabytes!  When you restore the window, it continues to utilized the lower memory amount, though it still increases in the same manner as we use it.

    Is this problem known about?  Are there ways to avoid this issue?

    Tuesday, July 20, 2010 5:24 PM

Answers

All replies

  • What makes you think there's a problem? This is a symptom of the lazy garbage collector in .net. 

    Tuesday, July 20, 2010 6:00 PM
  • Well, since you're using SL OOB, you can have it minimize and restore in code behind with a dispatcher timer - say every 5 minutes.

    I'm sure your users will love that. Of course, since you're doing a lot of graphics, their machines must be pretty fast, so they may not even notice.

    Tongue out 

    Tuesday, July 20, 2010 6:09 PM
  • What makes you think there's a problem? This is a symptom of the lazy garbage collector in .net. 

    Why would minimizing the window have anything to do with the GC running?  I suppose the Silverlight hosting code might manually be running the GC during that event, but the memory used to render new graphics needn't be held on to just because graphics are being displayed.  

    I'll experiment with running the GC manually through code to see if we get the same type of memory deallocation as when we minimize.


    Tuesday, July 20, 2010 6:51 PM
  • I'll experiment with running the GC manually through code to see if we get the same type of memory deallocation as when we minimize.

    Manually running GC.Collect did not deallocate the memory, so either there's some strange memory referencing that's going on while the Silverlight app is being displayed or there's some explicit freeing of resources in the event of minimization.


    Tuesday, July 20, 2010 7:02 PM
  • Minimizing a window triggers a clearing of the memory working set for the application. 

    Tuesday, July 20, 2010 7:22 PM
  • Minimizing a window triggers a clearing of the memory working set for the application. 

    Do you know of any other way to get this same clearing of memory to happen?  Obviously, this is not memory claimed by my code since running the GC doesn't have the same effect as the minimization.


    Tuesday, July 20, 2010 7:32 PM
  • http://www.google.co.uk/...

    Was there actually a useful link in there?  None of those search results have anything to do with things you can do in Silverlight.  

    Thanks for mentioning working set, though.  That got me to brush up on Windows memory terminology.  It seems like working set is a confusing metric for knowing how much memory your application is using.  Unfortunately, my private bytes are also growing without end, so there's either a memory leak in my code or in the Silverlight framework.  I'll see if a memory profiler will help.


    Wednesday, July 21, 2010 1:36 PM
  • The link was intended to show that there is not a programmatic way of trimming your working set, not from Silverlight anyway.

    If your memory usage appears to drop back to the same levels when you minimize the window, then this isn't something you should be worrying about. It's just normal behaviour. If your memory usage keeps increasing even after minimizing your window, then you'll have to identify where the leak is.

    Wednesday, July 21, 2010 2:02 PM
  • The private bytes of the application are only increasing when the application is not minimized.  Also, I ran a memory profiler on the application after getting it to consume large amounts of memory, and the objects allocated in our code are only a drop in the bucket compared to the total private bytes being used by sllauncher.  So it seems reasonable to conclude that the Silverlight rendering engine is badly leaking memory.

    Are there any tweaks one can make to a Silverlight application to prevent it from doing this?


    Wednesday, July 21, 2010 2:47 PM
  • If the memory goes down when the application is minimized, then it is not a leak

    Wednesday, July 21, 2010 6:05 PM
  • If the memory goes down when the application is minimized, then it is not a leak

    Please read more carefully.  Remember where I said:

    Unfortunately, my private bytes are also growing without end, so there's either a memory leak in my code or in the Silverlight framework.  I'll see if a memory profiler will help.

    The private bytes are increasing, which is unrelated to the working set minimization thing.


    Wednesday, July 21, 2010 6:35 PM
  • I highly suspect that this could be the cause:

    http://forums.silverlight.net/forums/p/171739/387384.aspx#387384

    We use inline templates all over the place.  I haven't had the time to investigate whether the workaround mentioned there has any effect.


    Wednesday, July 21, 2010 6:38 PM
  • @Apoco - Yea, that's the underlying issue - I hear mid August is when the fix is due.

     

    As for the whole minimising thing - yes, it does clear the memory, but it's still considered private memory, so no other application can use it - which agrees with what Apoco said in regards to Private Bytes.

    So yes, this is a memory leak.


    Thursday, July 22, 2010 2:12 AM
  • What kind of fix is this going to be? A point release? Is anything else going to be fixed? 

    Thursday, July 22, 2010 4:56 AM