views:

195

answers:

5

Hi,

Will the compiler optimize pretty formatted strings, or will that code run slower than strings that are not divided in a readable way?

for example

string sql = 
   "select * " +
   "from person " +
   "where id = :id";

or

string sql = "select * from person where id = :id";

This is just a small example. You know how complicated the sql can get.

+10  A: 

Just use:-

string sql = 
   @"select * 
     from person
     where id = :id";

This is from the compilers point of view identical to the single line solution. Although I wouldn't be surprised to see the concatenation of literal strings optimised out by the compiler anyway. However the common gotcha with the concatenation approach is forgetting to include whitespace at the end of string.

AnthonyWJones
Great tip about the "@" use. I've used the ampersand for many different other "string things", but never knew that it worked for multi line stuff!
kaze
Be aware that with the "@" syntax as shown you will end up with a different string than in the original: The carriage returns, linefeeds, and extra whitespace will all be included. So your string will be "select *\r\n from person\r\n where id = :id". In this case it doesn't matter much, but in some cases the difference is important.
Ray Burns
StackOverflow removed the extra whitespace from my prior comment. There should be five spaces after each "\r\n".
Ray Burns
@Ray: True and IMO desirable. When debugging code and you open a Text visualisation of the string content you see all the formatting remains intact. Variation in whitespace has no impact on SQL execution.
AnthonyWJones
LukeH
@Luke: Oh, I know, my brain and fingers were not communicating fully at the time of writing ;-)
kaze
+5  A: 

You can use

string s = @"SELECT *
FROM person
WHERE id = :id";
astander
+1 for letting the string "stick" to the left rather than indenting subsequent lines.
Kleinux
+4  A: 

String constants are folded at compile time so the two code fragments above are essentially identical.

Whether it's a good idea to have inline SQL string is another matter entirely...

Greg Beech
True, in my case though, I often have no choise but to use inline SQL, so I just want to make the best of the situation.
kaze
+4  A: 

Ah - one of the eternal verities of C#. Which is better, code that concatenates strings using + or code that doesn't? In your case, the answer depends on which version of .NET you're using .NET1 could only optimize the + string in a single statement so far. Too many + in a single string resulted in poorer performance as the compiler had to resort to creating new string instances to cope with additional string parts. From .NET 2, the architecture changed slightly, and multiple + statements are concatenated quite seamlessly by the compiler.

Pete OHanlon
Thanks for the downvote - whoever did it. Please explain why you think this answer is wrong so everybody can learn from it.
Pete OHanlon
+7  A: 

You can test this with a simple program:

Console.WriteLine("a" + "b");

Using reflector, you can easily disassemble the resulting binary. In Release mode, the IL this generates is:

L_0000: ldstr "ab"
L_0005: call void [mscorlib]System.Console::WriteLine(string)

So .NET does optimize "pretty formatted strings".

Andomar
Great answer :)
Thomas Bratt