There’s really something scary about when the whole foundation of your work starts to tremble because of some things not directly under your control. That’s what scares me the most about Microsoft being such a dominant force int the .NET ecosystem. Don’t get me wrong, there’s a LOT of good stuff happening because of Microsoft, and guys over there can be really helpful, but the latest troubles i encountered with the dreaded memory leakage really shook me up.
Long story short, there was a severe memory leak caused by inline datatemplates, and it’s one of the issues that, by far, got the most attention. What’s scary about it, it took 10 WHOLE MONTHS to get the issue sorted. The patch that took care of the issue was released just this week. Granted, you could go around it by not using inline templates (i’m not to fond of them anyway) but it really hurt a lot of people. That thread alone got 14 million view (!?) and it turned into a debate about Microsoft’s policies and release schedules.
You have a nice example there how to fill up your whole memory in 50 clicks of a button:) I won’t go much into detail here except that i did my own workaround for this problem, which only partially solves the problem, if you have the INotifDataErrorInfo under control. You can find a partial solution on the following link (won’t help with ria services entites though)
The good thing about this one is that it only REALLY affects you if you stay on one screen to long and refresh you data often. If you navigate between lists and grids, the entities will be released along with the controls so for most of the use cases it doesn’t really present THAT big of a problem. Still, you’d have to wonder, this issue has been known of for a looong time, and it’s still not resolved!
As for RIA Services users, this one could be easily resolved if only we had power to modify the abstract Entity class and put the code from the upper link insted of the strong referenced event. That is, if only RIA Services was open sourced, this issue would probably be solved in 5 days:).
Got an answer from kyle on this issue, still haven’t tried it though. This is a workaround:
Bing maps silverlight control
Well, i started using this control for my application, only to realize that this darn thing just likes to sit in memory. Actually, this was the first memory leak that i encountered in my application, so i decided to solve it by separating the control into a separate view and assigning it a dedicated viewmodel and making the whole thing a singleton. The good thing about the approach is that the map doesn’t get loaded repeatedly every time i navigate to page owning it, and it can be reused really easily. The bad thing is that it still locks the last page holding the map in the memory, but only the last one. I think that issue could easily be resolved, but i couldn’t be bothered honestly. In the end it turned out for the better.
Sky falling down on me
What really scared me is that once i started searching for the solution for that last problem, i couldn’t believe the sheer number of problems related to memory leaks haunting the whole silverlight ecosyste. I got scared shitless, so much that i really felt cheated because of investing into this technology at first. But once the passions settled down, i started thinking clearly and eliminated one problem at a time. There are still some weird problems with my application sometimes, not really memory related, but they’re no biggie. I just hope there’ll be more investment in bug fixing than feature adding.
This made me even more firm about my decision to go with open source technologies wherever possible (nhibernate, autofac, caliburn, etc…) because i just CAN’T rely on a 10 months bug repair cycle for my business.
Oh, i got this from the thread mention before, just a quick summary of some of the biggest pitfalls concerning memory leaks. Some of them might already be fixed, but be sure to check for yourselves.
1) Move inline DataTemplates to resources
2) Don’t reassign the ObservableCollection
3) Use one ContextMenu for a control like ItemsControl rather than a contextmenu in the ItemTemplate DataTemplate. Capture the current item datacontext with a MouseRightButtonDown handler for the ItemTemplate DataTemplate.
4) WCF RIA services users are probably running into this one: There is a memory leak with INotifyDataErrorInfo which Ria entities implement. I stopped binding views directly to RIA entities and instead use the approach described by this author: http://connect.microsoft.com/VisualStudio/feedback/details/562236/memory-leak-garbage-collection-issue-with-binding-to-subentities-in-silverlight-4-rtw
5) This might make a difference: Rather than bind to ObservableCollection
6) This is a kludge: After 10 minutes of inactivity I autosave the data, and after 60 minutes of inactivity I logout the user and reload the silverlight app. Inspired by code from http://bryantlikes.com/SearchView.aspx?q=logout and http://stackoverflow.com/questions/552756/can-silverlight-initiate-page-refreshes .