The key thing with any UI platform is that if you create a hierarchy of links, and you want to prune the head, you need to ensure the children get told a head of time that you're about to lop the head off. As it can leave markers open. In time the Garbage collection should figure it out that it's a dead marker, but none the less it pays to keep track of event subscription/notification channels along with bindings (which in a sense are part of the event traffic).
This goes for Flash, Silverlight, WPF, JavaScript etc. Sam: I suspect the problem you were having inside Flex was one I used to have many years ago, it could be a mixture of either EventDispatcher having close bindings or it could simply be a case of the Garbage Collection not behaving the way it should. I know in the past this has been somewhat of an issue with Flash and they've spent a lot of time in the last couple of revisions of Flash to try and resolve this but I've not seen proof that it's been resolved. If any of you have issues with Garbage Collection please please please let me know. I want to ensure that we don't repeat the mistakes Flash has had and cut that off at the pass. So send me your pain now! :) - -- Scott Barnes Rich Platforms Product Manager Microsoft Corp. | Blog: http://blogs.msdn.com/msmossyblog | Office: +1 (425) 5382410 X82410 Twitter: twitter.com/mossyblog | MSN: [email protected] Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John OBrien Sent: Wednesday, April 29, 2009 7:05 PM To: [email protected] Subject: RE: Memory leaks and garbage collection Sam, I'm building a GIS system with the new Virtual Earth Silverlight control and had a memory leak issue. The good news is I fixed it and it didn't take that long. I used Silverlight Spy to detect the leak and to confirm I had fixed it: http://silverlightspy.com/silverlightspy/download-silverlight-spy/ It turns out I was removing a child element that in turn had child elements that had both events and looping animations. The solution was to implement IDisposable and to stop the animations and detach the events on those objects. So bad news is that Silverlight doesn't magically solve memory leaks, good news is there are good tools to detect them and solutions to fix them. For those interested the scenario was deleting a MapLayer from the Map, the MapLayer contained hundreds of Custom Pushpins with animations, scale transformations hooked to the Map's onchangeViewFrame event and onclick event. It was easy enough to setup a layer to be added and removed every 5 sec in a manual unit test and check using Silverlight Spy. Love to know if people have found a way to automate this sort of test. John. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sam Lai Sent: Thursday, 30 April 2009 11:49 AM To: [email protected] Subject: Memory leaks and garbage collection Hi everyone, I've been working on a Flex app for a while now, and one of the most annoying things about it are memory leaks due to objects not being garbage collected. I'm not doing anything tricky, but I suspect it has something to do with bindings. The Flex Profiler doesn't always give enough information to exactly pinpoint it either. So as I'm about to start another project along similar lines, I'm wondering if people are experiencing similar issues in Silverlight, and how easy they were to resolve and avoid. Thanks, Sam -- Sent from my mobile device ---------------------------------------------------------------------------- ---- Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozsilverlight Other lists you might want to join: http://www.codify.com/lists -------------------------------------------------------------------------------- Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozsilverlight Other lists you might want to join: http://www.codify.com/lists -------------------------------------------------------------------------------- Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozsilverlight Other lists you might want to join: http://www.codify.com/lists
