Another potential gotcha when using nullables: Convert.ToInt32(x) returns zero when x==null. Same for ToInt64(), ToSingle(), etc.

Thanks for everyone's comments. My example is a little bit on the extreme side but it's to prove a point: that bad/incorrect use of structured exception handling CAN lead to performance problems.

The Programmers Heaven article does say in its conclusion that the performance hit of a try/catch block that never handles an exception is virtually nothing. I totally agree with that.

However, by virtue of having a try/catch block, there is the possibility that it WILL catch and handle an exception :-). I also think that many programmers will read the PH article and come out with the wrong conclusion that they should never worry about performance issues with exception handling.

Aaron: Great! Glad I could help :-)

I guess I didn't do a good job explaining the loop the first time. I am really comparing the code inside the loop. The for loop is only there to multiply the operation being measured thousands of times so that the final measurement is more accurate. It's the same idea as taking multiple samples and averaging them. If I didn't have the loop, the elapsed time would have been too small to accurately measure. For my test, the "operation" being measured is the concatenation of three string values, including the creation of the StringBuilder object.

jamesewelch:

Thanks for the tip about string.concat. I didn't know that string.Concat works differently than using the "+" operator (Concat allocates space for all the strings involved at once and avoids extra copying).

As for moving the creation of the StringBuilder object outside of the loop, that would invalidate the comparison. The purpose of the loop is to measure the entire StringBuilder "operation" multiple times to get a more accurate elapsed time.

It would be nice if the article talked about some modern alternatives for FTP.