This question is locked. New answers and comments are not allowed.
Elke.Eichelhard
Top achievements
Rank 1
Rank 1
Elke.Eichelhard
asked on 03 Apr 2012, 11:01 AM
We make extensive use of the ScheduleView in one of our business applications.
Unfortunately there seems to be a major memory leak within the RadScheduleView component, which leads to a massiv performance degeneration of the silverlight UI elements in general.
A simple demonstration would be the TV Schedule Demo: http://demos.telerik.com/silverlight/#ScheduleView/TVSchedule
A few minutes of scrolling left and right to force the component to redraw the appointments is sufficient. It seems like UI-components for the appointments - which should be discarded when scrolling out of view - are kept in memory and new UI-components are created whenever an appointment scrolls into view.
After a while silverlight in itselfs becomes sluggish, creating of new UI-elements takes seconds - the UI becomes unresponsive.
This is a huge problem for us, as it renders our application unusable after a few minutes of work.
There is a known bug related to grouping, but this behavior is apparent even when no grouping is used.
Unfortunately there seems to be a major memory leak within the RadScheduleView component, which leads to a massiv performance degeneration of the silverlight UI elements in general.
A simple demonstration would be the TV Schedule Demo: http://demos.telerik.com/silverlight/#ScheduleView/TVSchedule
A few minutes of scrolling left and right to force the component to redraw the appointments is sufficient. It seems like UI-components for the appointments - which should be discarded when scrolling out of view - are kept in memory and new UI-components are created whenever an appointment scrolls into view.
After a while silverlight in itselfs becomes sluggish, creating of new UI-elements takes seconds - the UI becomes unresponsive.
This is a huge problem for us, as it renders our application unusable after a few minutes of work.
There is a known bug related to grouping, but this behavior is apparent even when no grouping is used.
1 Answer, 1 is accepted
0
Hi,
This is very strange as we are making regular checks for memory leaks. We profiled similar application to the one in the demos with resources and lots of appointments but without the custom styles and after 7-8 minutes of scrolling there was a change in memory in the range of 500kb and also no ScheduleView classes that are not collected by the garbage collector.
Maybe there is something specific in a custom style or something else that is causing the slowdown.
Regards,
Boyan
the Telerik team
This is very strange as we are making regular checks for memory leaks. We profiled similar application to the one in the demos with resources and lots of appointments but without the custom styles and after 7-8 minutes of scrolling there was a change in memory in the range of 500kb and also no ScheduleView classes that are not collected by the garbage collector.
Maybe there is something specific in a custom style or something else that is causing the slowdown.
Regards,
Boyan
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>