efficient C# coding

  • Thread starter Thread starter Jack Fox
  • Start date Start date
J

Jack Fox

I'm looking for a good article on efficient C# coding. All the DotNet
efficient coding articles I can find are oriented toward VB.NET, and while
some principals still apply, many do not. For instance there is no
equivalent of



with (some object)

..

end with



in C# (or somebody straighten me out).



Somehow in the my early studies of C# I got the (apparently wrong)
impression that it had some kind of great compiler that made all the good
practices I learned in VB unnecessary. Consider the following:



private static void LoadHeadings(UltraWebGrid Grid, XmlNode[]
PrevHeadingArray, SortedList FootnoteList, int CurRow)

{

for (int i = 0; i < PrevHeadingArray.Length; i++)

{

Grid.Rows[CurRow].Cells.Text =
PrevHeadingArray.Attributes["text"].Value

+
SuperFootnotes(PrevHeadingArray.SelectNodes("child::note"),
FootnoteList);

Grid.Rows[CurRow].Cells.Style.VerticalAlign =
VerticalAlign.Top;

}

}



I need to access the same cell twice, and I do it down a fairly long path.
Nowhere have I seen it advised to assign the object to a local variable and
then access it, yet when I did that the following code generated
considerably less code in the debugger disassembly:



private static void LoadHeadings(UltraWebGrid Grid, XmlNode[]
PrevHeadingArray, SortedList FootnoteList, int CurRow)

{

for (int i = 0; i < PrevHeadingArray.Length; i++)

{

UltraGridCell oCell = Grid.Rows[CurRow].Cells;

oCell.Text = PrevHeadingArray.Attributes["text"].Value

+
SuperFootnotes(PrevHeadingArray.SelectNodes("child::note"),
FootnoteList);

oCell.Style.VerticalAlign = VerticalAlign.Top;

}

}



I can't really interpret the assembler code, but I figure less code is
usually a good proxy for more efficient code.



Judging from my VB experience the next step would be to assign
"PrevHeadingArray.Length" to a local integer. Am I on the right track?



I really don't have the time to pursue these interesting investigations, and
I haven't taken the time to instrument the example above and see what the
comparative elapsed times are, I would much rather read this all spelled-out
somewhere.
 
Good coding is good coding....it will always be possible to write
inefficient code with any language. Now, if I read your code correctly, I
see an UltraWebGrid which automatically makes you cool ;-).

You can simulate the With construct by declaring a DataGridRow and setting
the current row equal to it. You can reference each property independently.
I think you are on the right track. I don't think you'll see anything
glaring just by assigning the Lenght to a value based on your code below,
but if you reference it consistently then it's probably a good idea. The
places you'll see the biggest efficiencies is on items like DataRows in a
DataTable.

foreach(DataRow dro in myTable.Rows)
{
Debug.WriteLine(dro[0]) //vs Debug.WriteLine(dro[ColumnNameAsString])
//because each line has to resolve the name.

}

I think you are on the right track though Jack.

HTH.

Bill
Jack Fox said:
I'm looking for a good article on efficient C# coding. All the DotNet
efficient coding articles I can find are oriented toward VB.NET, and while
some principals still apply, many do not. For instance there is no
equivalent of



with (some object)

.

end with



in C# (or somebody straighten me out).



Somehow in the my early studies of C# I got the (apparently wrong)
impression that it had some kind of great compiler that made all the good
practices I learned in VB unnecessary. Consider the following:



private static void LoadHeadings(UltraWebGrid Grid, XmlNode[]
PrevHeadingArray, SortedList FootnoteList, int CurRow)

{

for (int i = 0; i < PrevHeadingArray.Length; i++)

{

Grid.Rows[CurRow].Cells.Text =
PrevHeadingArray.Attributes["text"].Value

+
SuperFootnotes(PrevHeadingArray.SelectNodes("child::note"),
FootnoteList);

Grid.Rows[CurRow].Cells.Style.VerticalAlign =
VerticalAlign.Top;

}

}



I need to access the same cell twice, and I do it down a fairly long path.
Nowhere have I seen it advised to assign the object to a local variable and
then access it, yet when I did that the following code generated
considerably less code in the debugger disassembly:



private static void LoadHeadings(UltraWebGrid Grid, XmlNode[]
PrevHeadingArray, SortedList FootnoteList, int CurRow)

{

for (int i = 0; i < PrevHeadingArray.Length; i++)

{

UltraGridCell oCell = Grid.Rows[CurRow].Cells;

oCell.Text = PrevHeadingArray.Attributes["text"].Value

+
SuperFootnotes(PrevHeadingArray.SelectNodes("child::note"),
FootnoteList);

oCell.Style.VerticalAlign = VerticalAlign.Top;

}

}



I can't really interpret the assembler code, but I figure less code is
usually a good proxy for more efficient code.



Judging from my VB experience the next step would be to assign
"PrevHeadingArray.Length" to a local integer. Am I on the right track?



I really don't have the time to pursue these interesting investigations, and
I haven't taken the time to instrument the example above and see what the
comparative elapsed times are, I would much rather read this all spelled-out
somewhere.
Click to expand...
 
At a basic level good code is pretty much language independent, but to go
beyond that level you need some clues as to what the compiler and operating
system are doing, and that is language dependent. (I realize that the CLR is
sort of a hybrid compiler and OS.) I'm slowly picking up some of these
clues, it would just be nice to benefit from someone else's experience if
they have already published on the topic.

Yep, using the 20 day trial version of UltraWebGrid. I do have one
usablility issue on the burner right now. Hopefully I'll figure it out soon.

William Ryan said:
Good coding is good coding....it will always be possible to write
inefficient code with any language. Now, if I read your code correctly, I
see an UltraWebGrid which automatically makes you cool ;-).

You can simulate the With construct by declaring a DataGridRow and setting
the current row equal to it. You can reference each property independently.
I think you are on the right track. I don't think you'll see anything
glaring just by assigning the Lenght to a value based on your code below,
but if you reference it consistently then it's probably a good idea. The
places you'll see the biggest efficiencies is on items like DataRows in a
DataTable.

foreach(DataRow dro in myTable.Rows)
{
Debug.WriteLine(dro[0]) //vs Debug.WriteLine(dro[ColumnNameAsString])
//because each line has to resolve the name.

}

I think you are on the right track though Jack.

HTH.

Bill
Jack Fox said:
I'm looking for a good article on efficient C# coding. All the DotNet
efficient coding articles I can find are oriented toward VB.NET, and while
some principals still apply, many do not. For instance there is no
equivalent of



with (some object)

.

end with



in C# (or somebody straighten me out).



Somehow in the my early studies of C# I got the (apparently wrong)
impression that it had some kind of great compiler that made all the good
practices I learned in VB unnecessary. Consider the following:



private static void LoadHeadings(UltraWebGrid Grid, XmlNode[]
PrevHeadingArray, SortedList FootnoteList, int CurRow)

{

for (int i = 0; i < PrevHeadingArray.Length; i++)

{

Grid.Rows[CurRow].Cells.Text =
PrevHeadingArray.Attributes["text"].Value

+
SuperFootnotes(PrevHeadingArray.SelectNodes("child::note"),
FootnoteList);

Grid.Rows[CurRow].Cells.Style.VerticalAlign =
VerticalAlign.Top;

}

}



I need to access the same cell twice, and I do it down a fairly long path.
Nowhere have I seen it advised to assign the object to a local variable and
then access it, yet when I did that the following code generated
considerably less code in the debugger disassembly:



private static void LoadHeadings(UltraWebGrid Grid, XmlNode[]
PrevHeadingArray, SortedList FootnoteList, int CurRow)

{

for (int i = 0; i < PrevHeadingArray.Length; i++)

{

UltraGridCell oCell = Grid.Rows[CurRow].Cells;

oCell.Text = PrevHeadingArray.Attributes["text"].Value

+
SuperFootnotes(PrevHeadingArray.SelectNodes("child::note"),
FootnoteList);

oCell.Style.VerticalAlign = VerticalAlign.Top;

}

}



I can't really interpret the assembler code, but I figure less code is
usually a good proxy for more efficient code.



Judging from my VB experience the next step would be to assign
"PrevHeadingArray.Length" to a local integer. Am I on the right track?



I really don't have the time to pursue these interesting investigations, and
I haven't taken the time to instrument the example above and see what the
comparative elapsed times are, I would much rather read this all spelled-out
somewhere.
Click to expand...
Click to expand...
 
Jack said:
Somehow in the my early studies of C# I got the (apparently wrong)
impression that it had some kind of great compiler that made all the good
practices I learned in VB unnecessary. Consider the following:
Click to expand...

I don't think the C# compiler is any more or less (at least noticably)
efficient than the VB compiler since they are both reduced down to
intermediate code and then "jittered" when the page is first called....
but I've never heard of anyone learning "good practices" from VB. Good
coding is good coding, like the others said, however, it is well known
that VB (especially in the Visual Studio environment) tends to reinforce
sloppy and lazy coding practice instead of good coding practices.

John
 
Well...I should have written "I wrote complex applications in VB that needed
optimized code to execute quickly, and thus I learned good VB coding
practices."

DevPartner TrueTime helped a lot. I'll have to pony up for the DotNet
version upgrade.

I'm always trying to wring out the last milliseconds of performace, but it
looks like the slowness in parts of my current application are not in my
code, but have more to do with the nature of HTTP (I'm necessarily producing
some large pages). I want an application that will scale up on the server
side. I don't know if the large pages only come up slowly on the client side
(which is acceptable) or if they also bog down the server. I'm developing on
an XP machine and don't yet have access to a true server.
 
Back
Top