|
Hello everyone,
I am using VS 2008, C# 3.5. Most of ppl in my group are Java ppl who are learnning C#. I am looking at a project in which the programmer is declaring everything as a user control ( even checkboxes) with no apparent need for this overmodulurization. And then adding those controls to the main form at run time.
Now I am arguing against this because this is a waste of reun time, and most of this should be done at design time.
What is your feedback? What is the drawbacks of this apporach? performance hits? can you provide links to literature so that I can share with other developers.
Thanks. | | kalamantina Tuesday, August 25, 2009 9:53 PM | All the code to add controls to a form resides in the InitializeComponent() method that is auto-generated by the Forms designer as you drag controls to the form surface. There's no performance difference as far as the computer is concernedif you write all this code, versus having the computer write the code for you. In the end, the code that's written to work properly will have to be the same, whether it's your fingers that have written it, or the designer that has generated it automatically. So to answer your question, it's not a waste of runtime. It's a waste of your personal time. Use the designer. Also, don't over abstract something. Leave a checkbox as a checkbox. No need to stuff it in another user control somewhere else. That will cause performance hits. Keep things simple, but modularize enough to keep your code clean.
Coding Light - Illuminated Ideas and Algorithms in SoftwareCoding Light Wiki � Twitter � LinkedIn � ForumsBrowser- Proposed As Answer byReed Copsey, Jr. Tuesday, August 25, 2009 10:23 PM
- Marked As Answer byKira QianMSFT, ModeratorTuesday, September 01, 2009 7:14 AM
-
| | David M Morton Tuesday, August 25, 2009 9:57 PM | Hi,
No, the designer file itself doesn't optimise performance, although in theory the IDE should generate optimal code in here (apparently that's not always the case though, especially in the Compact Framework). The designer file is really just a way of seperating the auto-generated code from your own.
While there might be slight differences, I think in most cases they would be immeasurable and I wouldn't worry about it from a runtime perspective. These slight differences would bebecausethere would be multiple InitializeComponent() methods (onein the form and in each user control rather than just the formone), but that's not likely to add a lot of overhead in itself. A bigger problem, as pointed out by David, is it is a waste of developer time, both in time it takes to write the code and for someone to understand it later.
Adding controls in the on load event shouldn't, most of the time, cause a peformance difference from doing so in the InitialiseComponent method... however I have read about some issues with controls like the ListView where apparently adding items before the window handle of the control is faster than adding them after, although this is probably irrelevant if you use BeginUpdate() and EndUpdate() appropriately.
It will also be using more memory... a user control hosting a checkbox will, I believe, be consuming at least two window handles. User and GDI resources are precious and should not be wasted, there have been a number of threads in these forums where people have run out of one or the other and had major problems because of it. I would recommend re-achitecting now, before it is too late.
Good luck.
- Marked As Answer byKira QianMSFT, ModeratorTuesday, September 01, 2009 7:14 AM
- Proposed As Answer byDavid M MortonMVP, ModeratorTuesday, August 25, 2009 11:57 PM
-
| | Yort Tuesday, August 25, 2009 10:22 PM | One thing I forgot to mention... this *is* (possibly, depending on implementation detail) a good design if your UI can be re-configured 'softly', i.e using a config file to database to specify which user controls to load and where to place them on screen. If you need that level of configurability, then this is not necessarily a bad way to go.
As to the window handle query,each user control is a 'window' as far as the operating system is concerned... that means it has a window handle, and at various times a bunch of GDI objects to handle painting itself. It also stores a bunch of information about the window, like it does for any other base window in the os, i.e border styles, locations, apperance values etc. Additionally, each one will send and receive window messages such as mouse move, key press etc. and have to pass those messages on down to their children when they have focus. That's not really going to cause too much of a performance problem in terms of the message processing or passing, but all the extra memory consumed by having additional windows created might, or might hurt you later on.
To clarify, if you have a form with 2 checkboxes and a text box you have approximately 4 window handles; 1 for the form, 1 for eachcheckbox box (2), and 1 one for the text box. If you place the checkboxes and textbox on a user control, you now have 5 window handles in use; 1 for the form, 1 for the user control, 1 for each checkbox (2) and 1 for the text box..
Just to clarify your original post, when you say 'user control' do you mean a user control as in when you right-click a project in solution explorer and say add new item -> user control, or are you referring to a checkbox as a user control in and of itself ? My post, and I think every one elses is assuming the former... if you are using the term user control to refer to any control from the toolbox, then we're misunderstanding.
- Marked As Answer byKira QianMSFT, ModeratorTuesday, September 01, 2009 7:14 AM
- Proposed As Answer byDavid M MortonMVP, ModeratorTuesday, August 25, 2009 11:57 PM
-
| | Yort Tuesday, August 25, 2009 10:41 PM | All the code to add controls to a form resides in the InitializeComponent() method that is auto-generated by the Forms designer as you drag controls to the form surface. There's no performance difference as far as the computer is concernedif you write all this code, versus having the computer write the code for you. In the end, the code that's written to work properly will have to be the same, whether it's your fingers that have written it, or the designer that has generated it automatically. So to answer your question, it's not a waste of runtime. It's a waste of your personal time. Use the designer. Also, don't over abstract something. Leave a checkbox as a checkbox. No need to stuff it in another user control somewhere else. That will cause performance hits. Keep things simple, but modularize enough to keep your code clean.
Coding Light - Illuminated Ideas and Algorithms in SoftwareCoding Light Wiki � Twitter � LinkedIn � ForumsBrowser- Proposed As Answer byReed Copsey, Jr. Tuesday, August 25, 2009 10:23 PM
- Marked As Answer byKira QianMSFT, ModeratorTuesday, September 01, 2009 7:14 AM
-
| | David M Morton Tuesday, August 25, 2009 9:57 PM | you mean as far as the clr is concerned, it will spend as much time loading both forms? what is the significance of the form.designer.cs file? doesn't that optimize performace? like a precompilation??
what if I go to the onload event and start adding those controls and docking them and bringtofront?
As for building your own user control and stuffing it into another user control, how would that waste resources? can you elaborate on that? | | kalamantina Tuesday, August 25, 2009 10:12 PM | Hi,
No, the designer file itself doesn't optimise performance, although in theory the IDE should generate optimal code in here (apparently that's not always the case though, especially in the Compact Framework). The designer file is really just a way of seperating the auto-generated code from your own.
While there might be slight differences, I think in most cases they would be immeasurable and I wouldn't worry about it from a runtime perspective. These slight differences would bebecausethere would be multiple InitializeComponent() methods (onein the form and in each user control rather than just the formone), but that's not likely to add a lot of overhead in itself. A bigger problem, as pointed out by David, is it is a waste of developer time, both in time it takes to write the code and for someone to understand it later.
Adding controls in the on load event shouldn't, most of the time, cause a peformance difference from doing so in the InitialiseComponent method... however I have read about some issues with controls like the ListView where apparently adding items before the window handle of the control is faster than adding them after, although this is probably irrelevant if you use BeginUpdate() and EndUpdate() appropriately.
It will also be using more memory... a user control hosting a checkbox will, I believe, be consuming at least two window handles. User and GDI resources are precious and should not be wasted, there have been a number of threads in these forums where people have run out of one or the other and had major problems because of it. I would recommend re-achitecting now, before it is too late.
Good luck.
- Marked As Answer byKira QianMSFT, ModeratorTuesday, September 01, 2009 7:14 AM
- Proposed As Answer byDavid M MortonMVP, ModeratorTuesday, August 25, 2009 11:57 PM
-
| | Yort Tuesday, August 25, 2009 10:22 PM | I just want to clarify, as my post maybe wasn't clear enough,
Right now the project has three layers of user controls, one control i a panel-UC1 for argument purposes - , on load this panel recieved two groupboxes ( each of course a another user control ) -UC1\2 for argument purposes -, each of those groupboxes hosts another set of user controls ( some checkboxes, a couple of dropdowns )-UC1 for argument purposes -. So no the MDI is just a skeleton hosting one large panel ( UC1 ) , UC1 is hosting 3 UC2, each UC2 is hosting 3 UC3, all in all, we have about 1 + 3 +6 = 10 user controls on the screen. This is not a performance hit?
Can you elaborate more on the window handles, each user control needs one?
| | kalamantina Tuesday, August 25, 2009 10:33 PM | One thing I forgot to mention... this *is* (possibly, depending on implementation detail) a good design if your UI can be re-configured 'softly', i.e using a config file to database to specify which user controls to load and where to place them on screen. If you need that level of configurability, then this is not necessarily a bad way to go.
As to the window handle query,each user control is a 'window' as far as the operating system is concerned... that means it has a window handle, and at various times a bunch of GDI objects to handle painting itself. It also stores a bunch of information about the window, like it does for any other base window in the os, i.e border styles, locations, apperance values etc. Additionally, each one will send and receive window messages such as mouse move, key press etc. and have to pass those messages on down to their children when they have focus. That's not really going to cause too much of a performance problem in terms of the message processing or passing, but all the extra memory consumed by having additional windows created might, or might hurt you later on.
To clarify, if you have a form with 2 checkboxes and a text box you have approximately 4 window handles; 1 for the form, 1 for eachcheckbox box (2), and 1 one for the text box. If you place the checkboxes and textbox on a user control, you now have 5 window handles in use; 1 for the form, 1 for the user control, 1 for each checkbox (2) and 1 for the text box..
Just to clarify your original post, when you say 'user control' do you mean a user control as in when you right-click a project in solution explorer and say add new item -> user control, or are you referring to a checkbox as a user control in and of itself ? My post, and I think every one elses is assuming the former... if you are using the term user control to refer to any control from the toolbox, then we're misunderstanding.
- Marked As Answer byKira QianMSFT, ModeratorTuesday, September 01, 2009 7:14 AM
- Proposed As Answer byDavid M MortonMVP, ModeratorTuesday, August 25, 2009 11:57 PM
-
| | Yort Tuesday, August 25, 2009 10:41 PM | Yort is quite right. There's nothing quite as expensive in Windows as a window object. A UserControl requires one, but does nothing very useful with it but as a container for its embedded controls. It has one great advantage, the Windows Forms designer is highly optimized for using a window as a designable object. But the cost you pay at runtime is very, very deer. Squeezing every notification it needs through the message pump is a great way to make a hotrod 3 Gigahertz CPU look like a 386SUX.
There's no excuse for using a UC to wrap a check box. Just derive from the CheckBox class directly. Saves you the incredible hassle too of reflecting all of its properties to UC properties as well.
Sorry David, you're quite wrong about this.
Hans Passant. | | nobugz Tuesday, August 25, 2009 11:23 PM | Sorry David, you're quite wrong about this.
So I am. I should have read the original post more clearly. I had interpreted it as, generally, whether it was more performant to put the code located in InitializeComponent() directly typed in the constructor or not. On rereading, it's obvious this wasn't the core of your question.
Yort is right. Please mark his post as answer. His explanation is excellent. I apologize for a hasty and poorly thought out response.
Coding Light - Illuminated Ideas and Algorithms in SoftwareCoding Light Wiki � Twitter � LinkedIn � ForumsBrowser | | David M Morton Wednesday, August 26, 2009 12:00 AM | Lighten up David, you don't have to fall on your sword. Let's leave it up to the OP.
Hans Passant. | | nobugz Wednesday, August 26, 2009 12:38 AM | Well Each control is a user control as in it inherits from the class System.Windows.Forms.Usercontrol.three of them is a small panel hosting 2 checkboxes.
Let me give you this scenario : theyhave now one LargePanelControl ( with nothing on it at design time ) , onload theyadd to it three Businesscontrols ( another panel, small sized, with about 4 small winforms control ( dropdowns, comboboxes ), Each of those businessCotnrols hosts 3 MiniatureUserControls which are added to the businesscontrol at design time.
So at runtime the only dynamic addition is the two businesscontrols, but each of them hosts three user controls on their own, so now the count is 10 controls and there are 13windows open on the screen? 1 LargePanelControl + 3 business controls + (3*3) 9 MiniatureUserControls = 13 | | kalamantina Wednesday, August 26, 2009 12:42 AM | Isn't thei a notion of precompilin here? is the designer.cs file part of that ? what is the signficance of the designer file?
Also I just want to get my technical terms clear, each user control is a window object or it requires a window handler? Can you clarify on that? | | kalamantina Wednesday, August 26, 2009 12:45 AM | "That's not really going to cause too much of a performance problem in terms of the message processing or passing"
Yort, I would imagine that this is a huge performance hit!! | | kalamantina Wednesday, August 26, 2009 12:47 AM | The designer does not precompile anything. The designer is simply a convenient place for the Visual Studio IDE to place all of the code concerning the basic layout of the form so that it's out of the way in the main .cs file, where you place your event handlers and interaction code.
Every user control requires a Windows handle (not handler) to run properly. This handle is used by the Windows Operating System as an "mailing address" so to speak, when it needs to send messages (such as mouse clicks, key presses, and paint events) to the user control. The user control then forwards these messages to the proper control within itself, ie, the TextBox or the CheckBox or the ComboBox.
Creating a user control simply to hold another single user control does nothing but add an additional Windows handle when there already is one (the ComboBox), effectively doubling the number of handles your application is dealing with. That's bad. Trying to keep the handle count down is good.
That being said, creating a custom user control in order to group a set of user controls that are commonly used together, where the functionality is repeated in more than one place in your application is good object oriented code and follows the DRY (Don't repeat yourself) principle.
Coding Light - Illuminated Ideas and Algorithms in SoftwareCoding Light Wiki � Twitter � LinkedIn � ForumsBrowser | | David M Morton Wednesday, August 26, 2009 12:54 AM | It could be, but I'm assuming thatprocessingmost window messages (except perhaps paint) is relatively fast, otherwise Windows would be slow... no obivous jokes please ;) | | Yort Wednesday, August 26, 2009 1:07 AM | No, there is no pre-compilation, it just a code storage/management feature. You can in fact move all the code in the designer into the main .cs file for a form, it won't be any slower and it will still work exactly the same. | | Yort Wednesday, August 26, 2009 1:07 AM | If it's inheriting from usercontrol, then my assumptions were correct and my previous posts should be relevant. | | Yort Wednesday, August 26, 2009 1:08 AM | Don't feel bad David... I initially mis-read your post and replied to it, then deleted my reply after I realised my mistake :) | | Yort Wednesday, August 26, 2009 1:09 AM | Well Each control is a user control as in it inherits from the class System.Windows.Forms.Usercontrol.three of them is a small panel hosting 2 checkboxes.
Let me give you this scenario : theyhave now one LargePanelControl ( with nothing on it at design time ) , onload theyadd to it three Businesscontrols ( another panel, small sized, with about 4 small winforms control ( dropdowns, comboboxes ), Each of those businessCotnrols hosts 3 MiniatureUserControls which are added to the businesscontrol at design time.
So at runtime the only dynamic addition is the two businesscontrols, but each of them hosts three user controls on their own, so now the count is 10 controls and there are 13windows open on the screen? 1 LargePanelControl + 3 business controls + (3*3) 9 MiniatureUserControls = 13
That sounds legitimate to me. Just keep the number of controls below 50 or so, you'd then use about as many window handles as Microsoft Outlook.
Hans Passant. - Proposed As Answer byYort Wednesday, August 26, 2009 1:34 AM
-
| | nobugz Wednesday, August 26, 2009 1:32 AM | David,
Thanks for the post, That is exactly what I wanted to understand.
I tried to lookup some docuemntationm on windows handle and user controls, and about the messages you described (mouse clicks, key presses, and paint events) but couldn';t find any, do you have any online articles about this that I can refer to?
Or if any one else can help with this, its appreciated.
| | kalamantina Wednesday, August 26, 2009 3:28 AM | Yort,
thanks for the reply, and no joke intended.
I only ask for more clarification ebcause I have to explain for a lot of Java and other old shool developers why this architecture is wrong, and justify it.
| | kalamantina Wednesday, August 26, 2009 3:29 AM | No problem :) | | Yort Wednesday, August 26, 2009 4:11 AM | David,
Thanks for the post, That is exactly what I wanted to understand.
I tried to lookup some docuemntationm on windows handle and user controls, and about the messages you described (mouse clicks, key presses, and paint events) but couldn';t find any, do you have any online articles about this that I can refer to?
Or if any one else can help with this, its appreciated.
kalamantina,
Try the following link, and click around. It should give you what you're looking for about handles:
This link gives in-depth detail on the message loop, which is where the messages are posted to the different controls:
Coding Light - Illuminated Ideas and Algorithms in SoftwareCoding Light Wiki � Twitter � LinkedIn � ForumsBrowser | | David M Morton Wednesday, August 26, 2009 9:51 AM | I'd like to add a couple of penniesto thistopicfor the 'old school' and Java developers that may not have the architecture completely wrong... The designer generated code may not be as optimized as it could be if the controls are added manually at run time - or by optimizing the designer generated code. I used this article http://msdn.microsoft.com/en-us/library/aa446535.aspxin .NET CF 1.0 and 2.0 to load the controls top down, and re-parent the controls instead of using Controls.Add() from the designer generated code,and I did indeed see anywhere from 30% to 60% performance improvement for the form load, depending on the complexity of the form. The disadvantage was that after the initial optimization work, you couldn't go back to the designer to make minor changes without the painful step of re-optimizing the designer generated code. After moving up the .NET CF 3.5, I just attempted to try this on a new form to see if it's still applicable.Now, I onlysee about a 5% performance improvement using the same technique. It seems that others have had a similar experience: http://social.msdn.microsoft.com/forums/en-US/windowsmobiledev/thread/9e6a0151-eedc-449b-8e26-6e56d9f69aee/The question then becomes, is the 5% performance improvement worth the extra time that will be spent in development and maintenence over using the designer. Also, just curious if anyone else has similar results to mine using this technique on .NET CF 3.5. | | Woody0 Tuesday, September 29, 2009 7:21 PM |
|
index > Windows Forms General > Difference in terms of performance between adding controls to a form at design time vs runtime