We have a large number of controls (be that a good or bad design principle) on a form, which seems to hog the CPU when the form is shown and not doing anything. You can recreate the problem by looping around 200 or so insertions of a RadLabel and RadTextBox into a FlowLayoutControl.
Is this a Rad controls problem or something else?
Best regards
Marek
Is this a Rad controls problem or something else?
Best regards
Marek
11 Answers, 1 is accepted
0
Hello Marek,
We know that in limited cases the CPU can get 100% when having many Telerik controls on the form, but are still unable to find what is the exact reason for that behavior.
We tried your exact scenario - 200 labels in FlowLayoutPanel and the CPU (3Ghz Intel and WinXP) indeed gets to 100% , but only when the form is being resized. Otherwise, the CPU is within normal limits.
If you are able to load the CPU to 100% systematically, we will be happy to debug the application and research the problems. We will also appreciate it if you send us exact step-by-step instructions on how to recreate your case.
We can transfer your Forum post to our support ticketing system to allow you to attach your test project, if needed.
Best wishes,
Angel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
We know that in limited cases the CPU can get 100% when having many Telerik controls on the form, but are still unable to find what is the exact reason for that behavior.
We tried your exact scenario - 200 labels in FlowLayoutPanel and the CPU (3Ghz Intel and WinXP) indeed gets to 100% , but only when the form is being resized. Otherwise, the CPU is within normal limits.
If you are able to load the CPU to 100% systematically, we will be happy to debug the application and research the problems. We will also appreciate it if you send us exact step-by-step instructions on how to recreate your case.
We can transfer your Forum post to our support ticketing system to allow you to attach your test project, if needed.
Best wishes,
Angel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
rbell
Top achievements
Rank 1
answered on 30 Aug 2007, 09:05 PM
Angel,
This is funny that this post was just posted! I have been spending the last two days trying to figure out why my app was doing the same thing. I thought it might have been related to some multithreading operations in my app. But then I narrowed it down to something very similar to what Marek experienced.
In my case I have a form that needs to be refreshed every so often. Every time its refreshed, it dynamically clears a panel's controls and then regenerates the controls for that panel. Each control in the panel is a user control made up of three RadTextBoxes and a single RadCheckBox.
I can probably mock a project up fairly quickly that will simulate the scenario if that will help. Just point me to a ticket!
By the way, replacing the rad controls with the standard winform control equivilents remedied the situation.
Randy
This is funny that this post was just posted! I have been spending the last two days trying to figure out why my app was doing the same thing. I thought it might have been related to some multithreading operations in my app. But then I narrowed it down to something very similar to what Marek experienced.
In my case I have a form that needs to be refreshed every so often. Every time its refreshed, it dynamically clears a panel's controls and then regenerates the controls for that panel. Each control in the panel is a user control made up of three RadTextBoxes and a single RadCheckBox.
I can probably mock a project up fairly quickly that will simulate the scenario if that will help. Just point me to a ticket!
By the way, replacing the rad controls with the standard winform control equivilents remedied the situation.
Randy
0
Hello rbell,
Just to be sure that we are talking about the same thing - what happens if the form is minimized? Is the CPU loaded to 100%? What happens if the form is restored?
We know that sometimes the CPU gets to 100% for 10 just controls on the form, but in other cases we are able to reproduce it with 200 controls. There is no obvious connection between the controls either.
The behavior is not stable and easily reproducible - it happens just sometimes, and it differs for each machines. For example, on a 3GHz Intel machine with WinXP and 1.5GB RAM, the problem appears with 2 forms opened and with 200 controls in each form. And it is not always happening. On a very similar machine, with similar process running, the 100% CPU utilization can be experienced with just one form with over 200 controls.
We are still researching what/where is the problem (is it on our controls, or is it in another process which interferes with our controls). We will appreciate your project and exact steps to reproduce the problem systematically, i.e. with 100% success. Please, open a support ticket to attach and send us the files.
Thank you in advance.
Regards,
Angel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Just to be sure that we are talking about the same thing - what happens if the form is minimized? Is the CPU loaded to 100%? What happens if the form is restored?
We know that sometimes the CPU gets to 100% for 10 just controls on the form, but in other cases we are able to reproduce it with 200 controls. There is no obvious connection between the controls either.
The behavior is not stable and easily reproducible - it happens just sometimes, and it differs for each machines. For example, on a 3GHz Intel machine with WinXP and 1.5GB RAM, the problem appears with 2 forms opened and with 200 controls in each form. And it is not always happening. On a very similar machine, with similar process running, the 100% CPU utilization can be experienced with just one form with over 200 controls.
We are still researching what/where is the problem (is it on our controls, or is it in another process which interferes with our controls). We will appreciate your project and exact steps to reproduce the problem systematically, i.e. with 100% success. Please, open a support ticket to attach and send us the files.
Thank you in advance.
Regards,
Angel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
rbell
Top achievements
Rank 1
answered on 31 Aug 2007, 01:45 PM
Angel,
I can't tell you whether or not it occurs when our form is minimized because we designed our form to act closer like a dialog box that can't be minimized. It is a singleton form - meaning that one and only one instance of the form exists and the OnClosing event is overriden to cancel the close and hide the form instead of actually closing it. This means the form is never actually closed or disposed of.
Essentially our form displays a bunch of reminders to the user. Each reminder consists of three telerik controls. It seems to be pushing the CPU at around 40 to 50 reminders - which equates to approximately 200 telerik controls on the form. When the form is "closed" (actually hidden) and a reminder is triggered, the form is then set to visible and the reminders refreshed by clearing the current reminders from the display and regenerating them.
My machine is a dual core AMD Athlon X2 running Windows XP with 2 Gig of RAM. Since it is a dual core, only one core is pushed to 100% so total cpu utilization is 50%. However, we have run this same app on other machines having a single core and it is pushed to 100%. But you are right in saying that it is inconsistant in that it occures at different times on different machines. However, since we essentially clear all the reminders and regenerate them on the form each time a reminder is triggered, the amount of controls cleared and created can grow quite high, and we are able to generate the issue quite consistantly - i.e. it always seems to occure...just a matter of when.
When I ran the app in debug mode, I would break the debugger and analyze the threads. It seemed that all the threads I generated were at a point where they should be (waiting for user action). So what ever the process that pushed the cpu seemed to be on an alternate thread. This was reflected by the fact that the app is still responsive when the cpu is pushed to 100%.
I analyzed the process using SysInternal's Process Explorer and it seems that the system level thread labeled "mscorwks.dll!CreateApplicationContext" was the culprit. Not sure if that helps.
The fact that it is inconsistant depending upon machine specs, leads me to suspect it might be something that gets triggered upon garbage collection - since garbage collection occurs on a seperate thread when the current allocated memory is running low. Since the allocated memory is a function of the machine specs I would expect that this would occure at different times on different machines.
Your thoughts?
Randy
PS. I just created a mock project that reacts the same as I described above. I just submitted it as a General Feedback ticket linking back to this discussion.
I can't tell you whether or not it occurs when our form is minimized because we designed our form to act closer like a dialog box that can't be minimized. It is a singleton form - meaning that one and only one instance of the form exists and the OnClosing event is overriden to cancel the close and hide the form instead of actually closing it. This means the form is never actually closed or disposed of.
Essentially our form displays a bunch of reminders to the user. Each reminder consists of three telerik controls. It seems to be pushing the CPU at around 40 to 50 reminders - which equates to approximately 200 telerik controls on the form. When the form is "closed" (actually hidden) and a reminder is triggered, the form is then set to visible and the reminders refreshed by clearing the current reminders from the display and regenerating them.
My machine is a dual core AMD Athlon X2 running Windows XP with 2 Gig of RAM. Since it is a dual core, only one core is pushed to 100% so total cpu utilization is 50%. However, we have run this same app on other machines having a single core and it is pushed to 100%. But you are right in saying that it is inconsistant in that it occures at different times on different machines. However, since we essentially clear all the reminders and regenerate them on the form each time a reminder is triggered, the amount of controls cleared and created can grow quite high, and we are able to generate the issue quite consistantly - i.e. it always seems to occure...just a matter of when.
When I ran the app in debug mode, I would break the debugger and analyze the threads. It seemed that all the threads I generated were at a point where they should be (waiting for user action). So what ever the process that pushed the cpu seemed to be on an alternate thread. This was reflected by the fact that the app is still responsive when the cpu is pushed to 100%.
I analyzed the process using SysInternal's Process Explorer and it seems that the system level thread labeled "mscorwks.dll!CreateApplicationContext" was the culprit. Not sure if that helps.
The fact that it is inconsistant depending upon machine specs, leads me to suspect it might be something that gets triggered upon garbage collection - since garbage collection occurs on a seperate thread when the current allocated memory is running low. Since the allocated memory is a function of the machine specs I would expect that this would occure at different times on different machines.
Your thoughts?
Randy
PS. I just created a mock project that reacts the same as I described above. I just submitted it as a General Feedback ticket linking back to this discussion.
0
Hi rbell,
Thank you for your efforts and desire to help - your points have been updated.
This issue is hard to debug because if we switch to VisualStudio and break the code execution we get into the normal message loop stack. We are not sure that the garbage collection is the reason for the CPU loading because it never stops - otherwise when the garbage collection is finished the CPU load would return to 0%.
We know that "mscorwks.dll!CreateApplicationContext" loads the CPU but for now we cannot understand why this is happening. We are researching the problem currently and will write back in the ticket you have opened on the topic.
Sincerely yours,
Angel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Thank you for your efforts and desire to help - your points have been updated.
This issue is hard to debug because if we switch to VisualStudio and break the code execution we get into the normal message loop stack. We are not sure that the garbage collection is the reason for the CPU loading because it never stops - otherwise when the garbage collection is finished the CPU load would return to 0%.
We know that "mscorwks.dll!CreateApplicationContext" loads the CPU but for now we cannot understand why this is happening. We are researching the problem currently and will write back in the ticket you have opened on the topic.
Sincerely yours,
Angel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Louis
Top achievements
Rank 1
answered on 17 Sep 2007, 06:21 PM
Is this bug will be fixed in the upcomming release ?
We are facing the same performance problems in our forms.
The loading time and resizing is horrible. Our forms contains more or less 30-40 controls.
thanks
We are facing the same performance problems in our forms.
The loading time and resizing is horrible. Our forms contains more or less 30-40 controls.
thanks
0
Hello Louis ,
Thank you for taking the time to write us. The problem you're describing is indeed rather unpleasant.
However, we are confident that it is not caused by the CPU load problem discussed in this thread. The CPU load problem describes a situation where the CPU load rises 100%, but that does not incur any performance penalty for the application, and loading and resizing times are normal.
The problem you're describing is a performance problem, caused by something not related to the CPU load problem. We realize this is an important problem, and we'd like to get more information on the specific scenario which causes it.
Could you open a support ticket and send us a sample project which reproduces the problem? Also, send us a sequence of steps to be followed to reproduce the problem.
Thanks again for letting us know about this problem. Your feedback is very important to letting us take our control suite where you would like it to be - the next level of functionality and ease of use. We appreciate it greatly.
Regards,
Kiril
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Thank you for taking the time to write us. The problem you're describing is indeed rather unpleasant.
However, we are confident that it is not caused by the CPU load problem discussed in this thread. The CPU load problem describes a situation where the CPU load rises 100%, but that does not incur any performance penalty for the application, and loading and resizing times are normal.
The problem you're describing is a performance problem, caused by something not related to the CPU load problem. We realize this is an important problem, and we'd like to get more information on the specific scenario which causes it.
Could you open a support ticket and send us a sample project which reproduces the problem? Also, send us a sequence of steps to be followed to reproduce the problem.
Thanks again for letting us know about this problem. Your feedback is very important to letting us take our control suite where you would like it to be - the next level of functionality and ease of use. We appreciate it greatly.
Regards,
Kiril
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Jiten
Top achievements
Rank 1
answered on 16 Mar 2009, 12:28 PM
Hi,
I am using the all Telerik WinForms Controls in my application. All forms are totally make by the Telerik WinForms Controls, like RadGridView, RadTabStrip, RadButton, RadLabel , RadTextbox etc. When i run my application then it uses more memory. Everytime when i open new form the the memory usage increases in the number of MBs. Is this the problem of Telerik Winforms Controls?
Please provide the the solution to use the low memory and can run the application with better performance.
Best Regards
I am using the all Telerik WinForms Controls in my application. All forms are totally make by the Telerik WinForms Controls, like RadGridView, RadTabStrip, RadButton, RadLabel , RadTextbox etc. When i run my application then it uses more memory. Everytime when i open new form the the memory usage increases in the number of MBs. Is this the problem of Telerik Winforms Controls?
Please provide the the solution to use the low memory and can run the application with better performance.
Best Regards
0
Hello Jiten,
Please download the latest release of our controls - Q1 2009. There are numerous improvements in this regard. Furthermore, more progress on that is expected in future.
Kind regards,
Nick
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Please download the latest release of our controls - Q1 2009. There are numerous improvements in this regard. Furthermore, more progress on that is expected in future.
Kind regards,
Nick
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
KR
Top achievements
Rank 1
answered on 19 May 2009, 07:44 AM
Hi,
I had purchased telerik control last year and few days back my support period has expired.
I am also facing the memory leakage issue. I tested it using Q1 2009 telerik controls and still the problem persists. The memory doesn't get released even after manually calling garbage collector.
Everytime a launch a form and close it, a certain amount of memory is occupied. It keeps on increasing everytime you open a form and close it. The memory is free once you close the entire application.
I am planning to use these controls in my new application which is in design phase right now but after looking at this issue I am bit nervous whether to go ahead with these controls or not.
Please suggest?
Thanks & Regards,
Kumud Ranjan
0
Hello KR,
We have fixed a memory leak in TPF which affected all our controls in Q1 2009; there should be no memory leaks in Q1 2009 SP1 though.
Please give it a go and write us back if you experience any problems.
Kind regards,
Nick
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
We have fixed a memory leak in TPF which affected all our controls in Q1 2009; there should be no memory leaks in Q1 2009 SP1 though.
Please give it a go and write us back if you experience any problems.
Kind regards,
Nick
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.