使用StringBuilder获取C＃中的常量字符串？

Question

In my current project they put every SQL query in a "QueryList" Class, each of them is a different Get method. What I don't understand is that they use StringBuilder in these methods to build a constant string, no manipulation or concatenation is used in them. When I questioned this, they said it was better then using concatenation. To what I know, concatenation of string literals is solved by the compiler, right? Is there some optimization for this kind of StringBuilder code in the compiler too?

I saw this similar question in Java ( Stringbuilder for Constants ), should be the same for C# ?

public static class QueryList
{
    private static StringBuilder GetQuery
    {
        get
        {
            StringBuilder query = new StringBuilder();

            query.Append(" INSERT INTO ");
            query.Append("  MyTable  ");
            query.Append("  (column1, column2)  ");
            query.Append(" VALUES ");
            query.Append("  (@val1 , @val2) ");

            return query;
        }
    }
}

and then in it's called as

string query = QueryList.GetQuery.ToString();

I made some counting and there's ~700 calls to these kind of methods, all followed by a ".ToString();" I know that when making actual string concatenation it'll be better, but there's only 34 calls that need it. There's something like 200 queries per seccond by the program.

Answer 1

If you want to return a constant string , just do it:

    // I've removed "Get" from the name
    private const string Query = 
      @"INSERT INTO MyTable (
          column1, 
          column2)
        VALUES (
          @val1, 
          @val2)";

there is no need in StringBuilder

Answer 2

Is there some optimization for this kind of StringBuilder code in the compiler

No. It will run every time.

There's no perfect way to embed multi-line string literals in C# (unfortunately). Of the options, this is my favorite for SQL queries:

        private static string SomeQuery
        {
            get
            {
                var query = @"
INSERT INTO
MyTable (column1, column2)
values (@val1, @val2)
";
                return query;
            }
        }

Answer 3

There's no optimization here - using the StringBuilder is not only pointless, but actively harmful to the code's efficiency. The property in question will always return the following string:

INSERT INTO   MyTable    (column1, column2)   VALUES   (@val1 , @val2)

That being said, if you're concatenating multiple string literals, any modern C# compiler will realize that it should do that at compile time rather than runtime. By way of example, consider the following code:

void Main()
{
    string a = "a" + "b" + "c";
    string b = "def";

    Console.WriteLine(a);
    Console.WriteLine(b);
}

Using LINQpad 5, this compiles to the following IL:

IL_0000:  nop         
IL_0001:  ldstr       "abc"
IL_0006:  stloc.0     // a
IL_0007:  ldstr       "def"
IL_000C:  stloc.1     // b
IL_000D:  ldloc.0     // a
IL_000E:  call        System.Console.WriteLine
IL_0013:  nop         
IL_0014:  ldloc.1     // b
IL_0015:  call        System.Console.WriteLine
IL_001A:  nop         
IL_001B:  ret 

Note in particular that "a" + "b" + "c" and "def" both result in the exact same IL - in other words, the tool is smart enough to realize that "a" + "b" + "c" is exactly the same as "abc" .

Now, consider this code:

void Main()
{
    var a = new StringBuilder();
    a.Append("a");
    a.Append("b");
    a.Append("c");
    string b = "def";

    Console.WriteLine(a.ToString());
    Console.WriteLine(b);
}

This translates to the following IL:

IL_0000:  nop         
IL_0001:  newobj      System.Text.StringBuilder..ctor
IL_0006:  stloc.0     // a
IL_0007:  ldloc.0     // a
IL_0008:  ldstr       "a"
IL_000D:  callvirt    System.Text.StringBuilder.Append
IL_0012:  pop         
IL_0013:  ldloc.0     // a
IL_0014:  ldstr       "b"
IL_0019:  callvirt    System.Text.StringBuilder.Append
IL_001E:  pop         
IL_001F:  ldloc.0     // a
IL_0020:  ldstr       "c"
IL_0025:  callvirt    System.Text.StringBuilder.Append
IL_002A:  pop         
IL_002B:  ldstr       "def"
IL_0030:  stloc.1     // b
IL_0031:  ldloc.0     // a
IL_0032:  callvirt    System.Object.ToString
IL_0037:  call        System.Console.WriteLine
IL_003C:  nop         
IL_003D:  ldloc.1     // b
IL_003E:  call        System.Console.WriteLine
IL_0043:  nop         
IL_0044:  ret

This is 25 instructions instead of 12 - in other words, the supposedly "better" code actually results in more than twice as much IL and greater memory consumption.

That being said, just use a literal const string (as some of the other answers have already pointed out).

It's also very strange to return a StringBuilder here unless they intend to add more stuff to the string later. If they're not doing that, they should just return a string. Or, in this case, a string constant would be even better, as @David Browne indicated.

This point may be a little more controversial, but making this a property rather than a public constant is kind of pointless and just adds needless overhead. Properties are ultimately syntactic sugar for method calls, whereas const string allows the compiler to do a text substitution at compile time rather than having to do a runtime method call.

TL;DR Just using a const string is far more efficient because the code shown in your example forces your program to do stuff at runtime that could easily be done at compile time.