Memory problem after disposing all telerik controls

[DenisCL]

Hello

I'm actually meeting a problem with Telerik control disposing, using the Q3 2010.3.10.1109.

I joined a screenshot showing an Ant Profiler Analysis, after we disposed manually all our Telerik Controls.

Actually, some RadPropertyValues and others things are not disposed.
Maybe We are doing something wrong while disposing.

Can you pelase tell is where these RadPropertyValues are coming from, and if it's possible to dispose it as all others telerik resources on the screenshot?

For your information, we added dispose() methods for each telerik controls.

Thanks for your lights

[Richard Slade]

Hello,

Have you looked to see if these objects are on the GC Root? They may well have had disposed called on them but the GC has not got around to collecting them yet.
Richard

[Jack]

Hello Denis,

Thank you for contacting us. Our TPF framework loads its themes as static components, so different controls can use the same theme objects. These static objects can contain a lot of RadPropertyValue objects that are not disposed until the application terminates. Nevertheless, there were some memory leaks in Q3 2010 that are addressed in our latest service pack. I recommend that you update your version. 

If you need further assistance, please do not hesitate to write back.

All the best,
Jack
the Telerik team

[DenisCL]

Hello,

We studied some case of our memories problems with your controls.

You will find here some screenshots regarding radlabel, radbutton and radDropDownlist, screenshot made with AntProfiler.
We can clearly see the items are not disposed and released because of a GC root far inside (from 10 to 20 placements)

Do you think there will be a critical update for this soon? Included in Q1  2011 for mid-March maybe?

We managed to optimize our coding in order to dispose a lot, but we still have about 15 - 20 Mo for each of the form.
A little computer with 512 mo ram memory will be out of memory after 5 usings.

Waiting for more information about this

Best Regards

[Jack]

Hello DenisCL,

Thank you for contacting us.

We take seriously all issues related to memory leaks and try to solve them with high priority. I will research this case in detail. It will be best if you can send me your application. This will help me to locate any potential issue faster.

Please note that our controls provide advanced theming and animation support and because of this they require more memory than the default MS controls. Our themes create static objects that persist in the application memory until it is terminated.

Thank you in advance for your understanding and cooperation.

I am looking forward to your project.

All the best,
Jack
the Telerik team

[DenisCL]

Hello Jack,

I managed to externalize this part of our project.

You can download it from here: Project

Just open, launch the application.
Click on "display visu". It will call out our window.
This visualisation is built dynamically from XML data deserialized.

if you click close, if you check the memory, a lot is not released.
Reopen, you'll see the mémory increasing.

If you get some errors when quitting application, it's "normal". I deleted the maximum I could in order to make this external project.

Best regards

[Jack]

Hi DenisCL,

Thank you for sending us your project. We will investigate the case in detail and I will write back when we have further information.  

Should you have any other questions, I will be glad to be of assistance.

 

Regards,
Jack
the Telerik team

[Jack]

Hi DenisCL,

I have an update on this issue.

I investigated your application in detail and performed strict memory leak tests. The result is unambiguous - everything on our side works as expected. However, I noticed that the cActeVenteCADManager class contains many complex objects which implement the IDisposable interface. Also, the class itself is not marked as IDisposable. An object of this class is instantiated every time when a new form is shown. All this leads to serious memory leaks. Please note, that all classes that implement the IDisposable interface should be disposed explicitly by calling their Dispose method. 

The logic of your application is complex and there are many classes and events. I am not sure that I understand correctly the application logic and that is why I could not do the modifications in your code. My advise is to implement the IDisposable intefrace for the cActeVenteCADManager and dispose all disposable resources when handling its Dispose method. 

In case you have any further questions or you need assistance, we will be glad to assist you.
 
Greetings,
Jack
the Telerik team

[DenisCL]

Hello,

I've implemented the IDisposable interface on the cActeVenteCADManager and disposed everything inside  + put everything to null in order to let GC take everything correctly.

This clas only contains a member which is a Form and fill it dynamically with UserControls containing RadControls.

But the problem still remains.
Is there finally no problems with the static members of RadControls's structure ?


Regards

[Jack]

Hello DenisCL,

As I said in my previous post, you have to dispose all dynamically created disposable objects explicitly. This includes the Form and all UserControls, including the child UserControls. We were not able to find any memory leaks in this scenario, however there are several static members that will be disposed when the application terminates. This is desired and these properties are used internally by our controls.

Should you have any further questions, do not hesitate to contact me.

Regards, Jack
the Telerik team

[Mark]

This is a reply just to place an emphasis on DenisCL's memory problems....with the intent to prompt Telerik to try and find a solution.

  We too are experiencing dibilitating memory depletion problems.  I've never experienced such rapid loss of memory in the 30 years I've been programming.  Our staff is out of ideas on how to remedy what should be a simple solution.  On close of a Form a Visual Studio application should return the memory that Form used....seems like a very basic logical requirement.  Prior to using the Telerik controls we used a Sybase technology called DW.Net.  Sybase EOL'd the product and we switched to Telerik controls that are very nice visually and feature rich.  The problem is they use a very large amount of memory. We did extensive meticulous testing and a cross comparison using Sybase datawindow grids and Telerik grids.  We experienced a 10 fold increase in memory using the Telerik grids for the same set of features. 

 

I am still hopeful that Telerik will try to find a comprehensive garbage collection solution on Close of a Form.  We really need this and there's just no way to overstate its importance.  Consecutively opening and then closing 20 large windows will freeze our application.  We have placed a memory usage indicator in the app to warn users of depleted memory resources, but data entry clerks across 4 states that must access many customer records continue to enter Help Desk tickets complaining about this.  The app is too large and too complex to send to Telerik and has been reviewed by several expert developers and we have not yet been able to find a solution. 

 All we require is for the application to restore memory used by a Form once it is closed....that's what we need.

[Hristo]

Hi Mark,

Thank you for writing. 

Please take a look at the following blog post as it provides additional information on the performance of Telerik controls: Performance considerations

I encourage you to open up a support ticket in which we can discuss your current application. If it is too big and it is not possible to be sent, you can create a demo project replicating your local set up. This is going to be the fastest way for us to investigate your case.

I hope this helps. Should you have further questions please do not hesitate to write back.

Regards,
Hristo Merdjanov
Telerik