views:

332

answers:

5

I have been playing a bit with Silverlight and try to port my Silverlight 3.0 application to Silverlight 4.0. My application loads different XAP files and upon a user request create an instance of a Xaml user control and adds it to the main container, in a sort of MEF approach in order I can have an extensible and pluggable application.

The application is pretty huge and to keep acceptable the performances and the initial loading I have built up some helper classes to load in the background all pages and user controls that might be used later on.

On Silverlight 3.0 everything was running smoothly without any problem so far. Switching to SL 4.0 I have noticed that when the process approaches to create the instances of the user controls the layout freezes unexpectedly for a minute and sometimes for more. Looking at the task manager the memory usage of IE jumps from 50MB to 400MB and sometimes up to 1.5 GB.

If the process won't take that much the layout is rendered properly even though the memory usage is still extremely high. Otherwise everything crashes due to out of memory exception.

Running the same application compiled in SL3, the memory used is about 200MB when all the usercontrols are loaded. Time spent to load the application in SL3 is about 10 seconds, while it takes up to 3 mins in SL4 There are no transparencies, no opacities set, no effects and animations in the layout.

User controls are instantied on the fly and added or removed in the visual tree on purpose when the user switches from one screen to another. The resources are all cleaned properly when a usercontrol is removed from the visual tree to allow the GC to operate in the background.

I may do something wrong but I could not figure out where exactly nail out the source of this problem. As far as I know there is no memory profiler in SL4 that can help me out to find where to look at. But again I could not be updated on new debugging tools available.

A: 

To be honest despite your assertion "The resources are all cleaned properly when a usercontrol is removed from the visual tree" this where I'd start looking. It really does smell of elements of UserControls not being released properly.

This typically occurs when there are long lived (for example static) objects that raise events that more transient objects attach to. If these event handlers aren't detached it leaves these objects hanging around in memory.

AnthonyWJones
Indeed it could be a warning, but to avoid any problem could raise from a missed unreleased event, I have not used any event of the type you suggest. Instead I have implemented a derivation of the proactor pattern (which is not commonly used). There is a thread, which runs in the background, that relays messages throughout the applications and the pluggable xaps for any usercontrol which subscribes to it, and filters the message type by the class attributes implemented.All the layout events such as clicks and user controls notification are released.
Marco
In the scenario where the application is initially loaded with all the user controls added to the visual tree, excluding any user interactions and therefore any need to release resources, SL uses the same amount of memory. To be more explicit, if the application starts by implementing all the user controls that I usually add during its lifetime, the amount of memory used by SL4 is still around 1.6 GB. And this should exclude any memory release issues, because no objects need to be removed.
Marco
I will, anyway check all the classes that subscribes to user events, even though the problem I encounter, I beleive, it is not related to this stage.When all the usercontrols are added to the XAML before compiling the application, the amount of time spent by SL4 to execute the application after being loaded is in a range of 3/4 mins. And the layout is totally frozen in the meanwhile.Those graphic behaviors points me to the UIThread, which I suppose, is asking for a huge amount of resources.
Marco
A: 

I am keep testing and would like to share what I discovered so far. It might be helpful to understand the behaviors of SL4.

Since it sounded pretty weird the UIThread can take so long to render a bunch of graphic components and considering Microsoft has improved the render pipeline, I have reverted my solution to SL3 but I have kept SL4 installed on my localhost.

The application uses RIA Services and moving back and forth to SL4 means that I have to do some changes in the code as per released documentation.

The application runs extremely smooth more than it was if it is tested with Visual Studio 2008. The memory usage is lower than it was before when SL4 wasn't installed.

As soon as I switch to VS2010 it is a completely different scenario. Memory grows undefinitely, the layout is slow to catch the user interaction and sometimes it freezes as before explained.

I have disabled RIA Services, by using standard Rest service and the process hasn't changed in quality.

In conclusion, considering I will keep testing in order I can finally understand what is really preventing to get the application running in an acceptable mode, I believe the memory issue is due to the debug process of VS 2010 or a combination of VS 2010 and SL4

Marco
A: 

Just for your info: there is a memory leak when using Silverlight Toolkit Charts in Silverlight 4.0. This is a known bug and Microsoft is working on it.

Sergei Golubev
A: 

Silverlight 4 is Leaking everywhere. It Doesn't release memory properly.

Jaime Bula
A: 

UPDATE:

Silverlight 4 Service Release to fix Memory Leaks: http://timheuer.com/blog/archive/2010/09/01/silverlight-service-release-september-2010-gdr1.aspx

Silverlight 4 has known memory leaks and the fix is currently being tested.

Here is a Microsoft Thread about it:

The user "heuertk" is a Microsoft Silverlight Developer....he explains the issues and the status of the fix...

http://forums.silverlight.net/forums/t/171739.aspx

gmcalab