It would be very useful and helpful for everyone if you could also post:
1. "Best practices" to avoid memory leaks with Silverlight (or Silverlight 4) with special focus on event handlers (especially with user controls and popup controls), datatemplates, styles, etc.
2. Best tools to help identify possible causes of memory leaks with Silverlight applications
3. General guidelines or steps to simplify XAML/Code for performance optimization and reduced XAP size (generic and not MVVM specific)
The 3rd one is bonus to us since we have been patient with the fixes! :)
I agree ... several Telerik controls are leaking (their SL equivalents are not leaking with the latest fix and the resource workaround). We need workarounds/fixes for those too. Especially the datagrid, treeview and combobox.
Please find the answer to your Telerik releated question on Telerik forums
here. If you have any Telerik releated problem please share it on our forums, because this way it will be handled by the same team members authering the respective control. Alternatively you can send me an email (on the address mentioned above) and I will
connect you with the appropriate team.
After moving all of my inline templates to static resources - first I've found that memory leaks were gone, then I've realized that editing datagrid - causing memory leaks too.
So I simply refactored all of my Navigation based pages to UserControl, I preload them on first time, and reuse them. And my app became much more faster :)
After moving all of my inline templates to static resources - first I've found that memory leaks were gone, then I've realized that editing datagrid - causing memory leaks too.
So I simply refactored all of my Navigation based pages to UserControl, I preload them on first time, and reuse them. And my app became much more faster :)
That's actually a great idea. For people who use MVVM, we simply need to switch the datacontext and we can reuse a lot of views since they're never gone. Voted!
I just want to second the request that any fix you come up with be released to more than just the 350 testers you had "test" the last one. You can say what you want about them being "real", but the fact is none of them found these issues over the course
of several months, and it took a few people in this thread less than 24 hours. If you have a policy that's not working, just change it. It benefits you and us.
Any guidance you can give regarding a timeline would be greatly appreciated. Unfortunately, I'm very close to the point of having to switch to a different technology. My customers don't want to hear excuses. They'll just go find another company who can deliver
a product that works in the real world. As much as I like what Silverlight promises, I may be forced to do the same. I'm sure I'm not the only one.
With all due respect, the lack of any approximate time frame is appalling. I understand and appreciate the many directions that the Silverlight team, like any dev team, is pulled on a daily basis. However, this is a HUGE issue. After attending the last
SL deep dive, we made the jump to start porting our line of business applications to Silverlight. However, with the current memory leaks our application becomes unstable after about 15 minutes of use. We've been incredibly worried about this for months but
thought, hey everybody understands the critical nature of memory leaks, Microsoft will get us home and fix it. We've been waiting months for an update that addresses the issue, the whole time in the dark as to when we might finally receive it; and when we
finally do it falls so short that I'm now faced with having to come up with something to tell my customers. Either 1) why our new application sucks so much that they really can't even use it or 2) why it is delayed and oh yeah, sorry but I don't have a timeline
for delivery.
Microsoft is touting Silverlight as a line of business platform. The people on this thread are not building a cute little video player out on the web. This is enterprise, what companies rely on each and every day to run their businesses. When a customer
reports a critical bug to us, we're fixing it immediately. We're on hourly or daily calls with updates until it's resolved. If I told them "sorry, I just don't have a time frame unfortunately" I'd lose all of my customers in very short order.
I can't stress enough how important this issue is, not just to us but to every company out there building or considering building line of business applications on Silverlight. If this isn't addressed shortly, there's no way anybody out there is going to
risk their neck and say, hey, lets build this new app on Silverlight - they'd be a fool...
I urge you to work with the dev team to resolve this/these leaks as quickly as possible WHILE providing communication back to the community on progress and time lines. None of us can build in the dark. We need all of the help we can get if this is going
to be a viable platform for these types of applications.
valiant_sam
Member
67 Points
33 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 04:08 AM | LINK
Tim,
It would be very useful and helpful for everyone if you could also post:
1. "Best practices" to avoid memory leaks with Silverlight (or Silverlight 4) with special focus on event handlers (especially with user controls and popup controls), datatemplates, styles, etc.
2. Best tools to help identify possible causes of memory leaks with Silverlight applications
3. General guidelines or steps to simplify XAML/Code for performance optimization and reduced XAP size (generic and not MVVM specific)
The 3rd one is bonus to us since we have been patient with the fixes! :)
amine.boussema
Member
14 Points
7 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 05:25 AM | LINK
I vote with valiant.
I add another important point (perhaps related to telerik library) : how to use Telerik controls now, before the next release, to avoid Mem. Leaks ?
stduserid
Member
140 Points
67 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 05:55 AM | LINK
I agree ... several Telerik controls are leaking (their SL equivalents are not leaking with the latest fix and the resource workaround). We need workarounds/fixes for those too. Especially the datagrid, treeview and combobox.
ligaz
Member
16 Points
3 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 09:26 AM | LINK
Hi all,
Please find the answer to your Telerik releated question on Telerik forums here. If you have any Telerik releated problem please share it on our forums, because this way it will be handled by the same team members authering the respective control. Alternatively you can send me an email (on the address mentioned above) and I will connect you with the appropriate team.
Thanks,
Stefan
ManuelFelicio
Participant
986 Points
238 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 10:47 AM | LINK
Hi,
I think no one answered a question I asked. Does declaring inline datatemplates inside static resource datatemplates still leak?
Best regards,
Manuel Felício,
ggercman
Member
2 Points
1 Post
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 11:31 AM | LINK
Actually it still leaks almost everywhere.
After moving all of my inline templates to static resources - first I've found that memory leaks were gone, then I've realized that editing datagrid - causing memory leaks too.
So I simply refactored all of my Navigation based pages to UserControl, I preload them on first time, and reuse them. And my app became much more faster :)
ManuelFelicio
Participant
986 Points
238 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 11:49 AM | LINK
That's actually a great idea. For people who use MVVM, we simply need to switch the datacontext and we can reuse a lot of views since they're never gone. Voted!
fwanicka
Member
74 Points
52 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 01:12 PM | LINK
I just want to second the request that any fix you come up with be released to more than just the 350 testers you had "test" the last one. You can say what you want about them being "real", but the fact is none of them found these issues over the course of several months, and it took a few people in this thread less than 24 hours. If you have a policy that's not working, just change it. It benefits you and us.
Any guidance you can give regarding a timeline would be greatly appreciated. Unfortunately, I'm very close to the point of having to switch to a different technology. My customers don't want to hear excuses. They'll just go find another company who can deliver a product that works in the real world. As much as I like what Silverlight promises, I may be forced to do the same. I'm sure I'm not the only one.
gmcalab
Member
10 Points
5 Posts
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 02:19 PM | LINK
Infragistics XamGrid and XamCombo leak as well from what I can see... I applied the patch and they appear to be leaking still.
gcp
Member
2 Points
1 Post
Re: Re: Re: Re: Re: Re: Re: Memory Leak
Sep 08, 2010 02:56 PM | LINK
With all due respect, the lack of any approximate time frame is appalling. I understand and appreciate the many directions that the Silverlight team, like any dev team, is pulled on a daily basis. However, this is a HUGE issue. After attending the last SL deep dive, we made the jump to start porting our line of business applications to Silverlight. However, with the current memory leaks our application becomes unstable after about 15 minutes of use. We've been incredibly worried about this for months but thought, hey everybody understands the critical nature of memory leaks, Microsoft will get us home and fix it. We've been waiting months for an update that addresses the issue, the whole time in the dark as to when we might finally receive it; and when we finally do it falls so short that I'm now faced with having to come up with something to tell my customers. Either 1) why our new application sucks so much that they really can't even use it or 2) why it is delayed and oh yeah, sorry but I don't have a timeline for delivery.
Microsoft is touting Silverlight as a line of business platform. The people on this thread are not building a cute little video player out on the web. This is enterprise, what companies rely on each and every day to run their businesses. When a customer reports a critical bug to us, we're fixing it immediately. We're on hourly or daily calls with updates until it's resolved. If I told them "sorry, I just don't have a time frame unfortunately" I'd lose all of my customers in very short order.
I can't stress enough how important this issue is, not just to us but to every company out there building or considering building line of business applications on Silverlight. If this isn't addressed shortly, there's no way anybody out there is going to risk their neck and say, hey, lets build this new app on Silverlight - they'd be a fool...
I urge you to work with the dev team to resolve this/these leaks as quickly as possible WHILE providing communication back to the community on progress and time lines. None of us can build in the dark. We need all of the help we can get if this is going to be a viable platform for these types of applications.
Best Regards
Geoff