|
First code snippet
<br />
for(int i=1;i<=100;i++)<br />
DropDownList1.Items.Add(new ListItem(i.ToString(),i.ToString()));<br />
Second Code Snippet
<br />
DropDownList1.Items.Add(new ListItem("1","1"));<br />
DropDownList1.Items.Add(new ListItem("2","2"));<br />
DropDownList1.Items.Add(new ListItem("3","3"));<br />
DropDownList1.Items.Add(new ListItem("4","4"));<br />
DropDownList1.Items.Add(new ListItem("5","5"));<br />
DropDownList1.Items.Add(new ListItem("6","6"));<br />
DropDownList1.Items.Add(new ListItem("7","7")); <br />
DropDownList1.Items.Add(new ListItem("8","8")); <br />
.<br />
.<br />
.<br />
.<br />
DropDownList1.Items.Add(new ListItem("99","99")); DropDownList1.Items.Add(new ListItem("100","100"));<br />
<br />
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|
not really the right forum for this.
but.
methink the first alternative is the simplest, the fasted and can be the easiest to maintain in the long run.
|
|
|
|
|
If you'd posted the second as an example of what somebody has done then I would say this was a perfect coding horror.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
It happened long time back with one of my friend, He was working in a company and his colleague wrote all hundred lines of code to populate drop down listbox.
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|
I can see how this could be done in a script language, where there is no benefit to keeping the data outside of the application, i.e. actually use the multiple statements to define the content of the list.
|
|
|
|
|
sylvesterg wrote: wrote all hundred lines of code to populate drop down listbox.
And if that is JavaScript, the amount of page size (ViewSource) that travels down the Internet pipe is really phenomenal.
|
|
|
|
|
The first one is much better coding.
The second one I would predict to be a nanosecond or something faster.
The reason being the first one has to create a loop, some tostrings, an int etc....
And it still creates the same ammount of listitems, and such.
The second on would make a larger dll, but probably execute a smidget faster cause of less resources..... but.... NEVER EVER DO THAT unless you have like 2 items or something small and ridicuous.
The performance difference is not even close to being worth the pain of working on code like that.
So... for(...) wins hands down.
http://www.jonavi.com
|
|
|
|
|
There's usually an unroll-loop option in most compilers.
|
|
|
|
|
The first one is certainly slower, since the compiler will have to evaluate two additional commands for every loop... but is certainly better in terms of maintainability.
|
|
|
|
|
The second one is faster I think (with a couple of µs that is)
The first one is far, far better.
V.
I found a living worth working for, but haven't found work worth living for.
|
|
|
|
|
Any improvement in speed the second may have pales in comparison to the cost in maintainability.
Any why have both values be strings?
And why have a DropDownList simply to select a number? Use a NumericUpDown or a TextBox with validation.
I really dislike Websites that have a list of (U.S.) state abbreviations or whatnot when it's simpler just to type in the data... e.g. I now live in Arizona, but rather than allowing me to enter "AZ" (two keystrokes) I need to either scroll down or press "A" five times! Just so the programmer doesn't have to validate the entry, pathetic.
|
|
|
|
|
sylvesterg wrote: which one is faster
It is easy to check: just make a loop with a couple of million items to add, and then type the second version up to the same number, and you'll be able to measure it with a stopwatch.
|
|
|
|
|
The best is use make an array with the strings and after use items.AddRange, and also for Painting part.
|
|
|
|
|
I'd go with the first as being better. Besides, the overhead in "DropDownList1.Items.Add()" itself is enough to mask any possible speed difference between the two constructs. Really, both should execute fast enough that you won't notice it anyway. Speed diff can be so easily lost due to random interrupts and kernel scheduling variations that it becomes a "who cares" issue for the most part.
And the explicit one... what a nightmare to maintain.
|
|
|
|
|
The first is the better because it is more readable and bug-safer. In the second you have to paste and copy too much.
I would write
String s;//here
for(int i=1;i<=100;i++)
{
const String s = i.ToString();//could be best, so let the compiler do the optimzing !!!
DropDownList1.Items.Add(new ListItem(s,s));
}
so I win one call
The first one is the best for the programmer - so what second 
Greetings from Germany
|
|
|
|
|
Would it be better to do the call to i.ToString() only once and assign it to a variable?
Being in a minority of one, doesn't make you insane
George Orwell
However, in my case it does
|
|
|
|
|
The latter method is somewhat like C++ inline qualifier for function right?
|
|
|
|
|
First, you are not supposed to ask questions here.
Now, on modern day machines it does not matter that much. The second would be faster, at least it use to be and is called unrolling. In the old days the difference would be noticeable by the user and is why unrolling loops was sometime needed, especially in graphics applications. In this case the new operation is more of a bottle neck than the loop, but pre-allocating memory space can help solve that problem.
Any way,
Just use the loop form, as it is easier to maintain and you probably do not have a legitimate reason not to.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Recently a contractor(my View about Contractors - are supposed to good programmers!) worked in our project.
Code written in C#-VS2005
He wrote
<br />
public void RegisterEvents()<br />
{<br />
obj.CenterChanged += new CenterChangedEventHandler(OnCenterChanged);<br />
obj.CenterChanged += new CenterChangedEventHandler(OnCenterChanged);<br />
}<br />
My question:
Would registering the same event twice call the handler twice when event is raised?
-rt
|
|
|
|
|
I did a quick check myself and indeed the handler gets called twice if registered twice.
The handler handled some drawing code which I am sure would redraw twice!
|
|
|
|
|
Contractors aren't magic bullets for organisations. Like every other profession, some are good and some are bad. Remember that a lot of people are attracted to contracting for the perceived high remuneration and you can see why there is a lot of chaff among the wheat.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
|
Yeah it should get called twice
I find a number of contractors are hackers because they just code to the contract with no thought to maintainability.
I'm sure there are some good ones out there, but they are much more immediate result oriented, which can lead to bad code. I've seen it a few times, not to say permanent coders can't be hackers too.
Tim
|
|
|
|
|
True. Their sense of commitment to the organization is less since they know they would escape after a while.
We need to be careful in getting the proper deliverables from them since our project is billed by them.
|
|
|
|
|
Yes.
But wasn't there a compiler warning or at least a peer code review to stamp out this? 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
