More on string concatenation performance
This one is kind of obvious when you think about it, but I've seen code like this so many times it's probably worth showing. Strangely enough, I've seen this kind of code in VB most of the time.
The reason why people write this kind of code is to construct a SQL query while keeping the source code easily readable by splitting the string across several lines of code. The code looks like this:
string a = "Some string that we want to build";
a += " from several strings for better";
a += " source code readability:";
a += " we don't want a long string on one line.";
Notice how the string has the new bit added to itself using concatenation (in VB, you would use &= instead of +=). This is of course not very efficient because real concatenations happen. Here's the IL that this code compiles to:
ldstr "Some string that we want to build"
stloc.0
ldloc.0
ldstr " from several strings for better"
call string [mscorlib]System.String::Concat(string, string)
stloc.0
ldloc.0
ldstr " source code readability:"
call string [mscorlib]System.String::Concat(string, string)
stloc.0
ldloc.0
ldstr " we don't want a long string on one line."
call string [mscorlib]System.String::Concat(string, string)
It's much more efficient to really split the line without ending it, this way:
string a = "Some string that we want to build"
+ " from several strings for better"
+ " source code readability:"
+ " we don't want a long string on one line.";
The IL that this code compiles to is exactly equivalent to what you'd get if you had left the string on one line because the compiler knows that only static strings are concatenated here:
ldstr "Some string that we want to build from several str"
+ "ings for better source code readability: we don't want a long string on"
+ " one line."
+ signs here are an artefact of ILDASM for readability, similar to what we're trying to do in our source code, and are not real concatenations: notice how the lines are split at different places when compared to our source. To make it perfectly clear: the + signs here are *not* real. If you read the exe file with a hex editor, you'll see that the string is in one piece. No quotes, no concatenation, nothing.
So you get both readability and optimal performance.
In VB, of course, you can use the line continuation symbol (underscore: _ ) and the & operator. The compiler will also optimize it to a single string.