何时使用 StringBuilder？

A single concatenation is not worth using a StringBuilder. I've typically used 5 concatenations as a rule of thumb.

Not really...you should use StringBuilder if you concatenate large strings or you have many concatenations, like in a loop.

But if I want to concatenate 2 strings, then I assume that it's better and faster to do so without StringBuilder. Is this correct?

Yes. But more importantly, it is vastly more readable to use a vanilla String in such situations. Using it in a loop, on the other hand, makes sense and can also be as readable as concatenation.

I’d be wary of rules of thumb that cite specific numbers of concatenation as a threshold. Using it in loops (and loops only) is probably just as useful, easier to remember and makes more sense.

I warmly suggest you to read The Sad Tragedy of Micro-Optimization Theater, by Jeff Atwood.

It treats Simple Concatenation vs. StringBuilder vs. other methods.

Now, if you want to see some numbers and graphs, follow the link ;)

But if I want to concatinate 2 strings, then I assume that it is better (faster) to do it without StringBuilder. Is this correct?

That is indeed correct, you can find why exactly explained very well on :

Article about strings and StringBuilder

Summed up : if you can concatinate strings in one go like

var result = a + " " + b  + " " + c + ..

you are better off without StringBuilder for only on copy is made (the length of the resulting string is calculated beforehand.);

For structure like

var result = a;
result  += " ";
result  += b;
result  += " ";
result  += c;
..

new objects are created each time, so there you should consider StringBuilder.

At the end the article sums up these rules of thumb :

Rules Of Thumb

So, when should you use StringBuilder, and when should you use the string concatenation operators?

• Definitely use StringBuilder when you're concatenating in a non-trivial loop - especially if you don't know for sure (at compile time) how many iterations you'll make through the loop. For example, reading a file a character at a time, building up a string as you go using the += operator is potentially performance suicide.

• Definitely use the concatenation operator when you can (readably) specify everything which needs to be concatenated in one statement. (If you have an array of things to concatenate, consider calling String.Concat explicitly - or String.Join if you need a delimiter.)

• Don't be afraid to break literals up into several concatenated bits - the result will be the same. You can aid readability by breaking a long literal into several lines, for instance, with no harm to performance.

• If you need the intermediate results of the concatenation for something other than feeding the next iteration of concatenation, StringBuilder isn't going to help you. For instance, if you build up a full name from a first name and a last name, and then add a third piece of information (the nickname, maybe) to the end, you'll only benefit from using StringBuilder if you don't need the (first name + last name) string for other purpose (as we do in the example which creates a Person object).

• If you just have a few concatenations to do, and you really want to do them in separate statements, it doesn't really matter which way you go. Which way is more efficient will depend on the number of concatenations the sizes of string involved, and what order they're concatenated in. If you really believe that piece of code to be a performance bottleneck, profile or benchmark it both ways.

System.String is an immutable object - it means that whenever you modify its content it will allocate a new string and this takes time (and memory?). Using StringBuilder you modify the actual content of the object without allocating a new one.

So use StringBuilder when you need to do many modifications on the string.

There's no definitive answer, only rules-of-thumb. My own personal rules go something like this:

• If concatenating in a loop, always use a StringBuilder.
• If the strings are large, always use a StringBuilder.
• If the concatenation code is tidy and readable on the screen then it's probably ok.
  If it isn't, use a StringBuilder.

I don't think there's a fine line between when to use or when not to. Unless of course someone performed some extensive testings to come out with the golden conditions.

For me, I will not use StringBuilder if just concatenating 2 huge strings. If there's loop with an undeterministic count, I'm likely to, even if the loop might be small counts.

As long as you can physically type the number of concatenations (a + b + c ...) it shouldn't make a big difference. N squared (at N = 10) is a 100X slowdown, which shouldn't be too bad.

The big problem is when you are concatenating hundreds of strings. At N=100, you get a 10000X times slowdown. Which is pretty bad.

To paraphrase

Then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch

I generally use string builder for any block of code which would result in the concatenation of three or more strings.

• If you concatenate strings in a loop, you should consider using StringBuilder instead of regular String
• In case it's single concatenation, you may not see the difference in execution time at all

Here is a simple test app to prove the point:

static void Main(string[] args)
{
//warm-up rounds:
Test(500);
Test(500);


//test rounds:
Test(500);
Test(1000);
Test(10000);
Test(50000);
Test(100000);


Console.ReadLine();
}


private static void Test(int iterations)
{
int testLength = iterations;
Console.WriteLine($"----{iterations}----");


//TEST 1 - String
var startTime = DateTime.Now;
var resultString = "test string";
for (var i = 0; i < testLength; i++)
{
resultString += i.ToString();
}
Console.WriteLine($"STR: {(DateTime.Now - startTime).TotalMilliseconds}");






//TEST 2 - StringBuilder
startTime = DateTime.Now;
var stringBuilder = new StringBuilder("test string");
for (var i = 0; i < testLength; i++)
{
stringBuilder.Append(i.ToString());
}
string resultString2 = stringBuilder.ToString();
Console.WriteLine($"StringBuilder: {(DateTime.Now - startTime).TotalMilliseconds}");




Console.WriteLine("---------------");
Console.WriteLine("");


}

Results (in milliseconds):

----500----
STR: 0.1254
StringBuilder: 0
---------------


----1000----
STR: 2.0232
StringBuilder: 0
---------------


----10000----
STR: 28.9963
StringBuilder: 0.9986
---------------


----50000----
STR: 1019.2592
StringBuilder: 4.0079
---------------


----100000----
STR: 11442.9467
StringBuilder: 10.0363
---------------

Since it's difficult to find an explanation for this that's not either influenced by opinions or followed by a battle of prides I thought to write a bit of code on LINQpad to test this myself.

I found that using small sized strings rather than using i.ToString() changes response times (visible in small loops).

The test uses different sequences of iterations to keep time measurements in sensibly comparable ranges.

I'll copy the code at the end so you can try it yourself (results.Charts...Dump() won't work outside LINQPad).

Output (X-Axis: Number of iterations tested, Y-Axis: Time taken in ticks):

Iterations sequence: 2, 3, 4, 5, 6, 7, 8, 9, 10

Iterations sequence: 10, 20, 30, 40, 50, 60, 70, 80

Iterations sequence: 100, 200, 300, 400, 500

Code (Written using LINQPad 5):

void Main()
{
Test(2, 3, 4, 5, 6, 7, 8, 9, 10);
Test(10, 20, 30, 40, 50, 60, 70, 80);
Test(100, 200, 300, 400, 500);
}


void Test(params int[] iterationsCounts)
{
$"Iterations sequence: {string.Join(", ", iterationsCounts)}".Dump();
    

int testStringLength = 10;
RandomStringGenerator.Setup(testStringLength);
var sw = new System.Diagnostics.Stopwatch();
var results = new Dictionary<int, TimeSpan[]>();
        

// This call before starting to measure time removes initial overhead from first measurement
RandomStringGenerator.GetRandomString();
        

foreach (var iterationsCount in iterationsCounts)
{
TimeSpan elapsedForString, elapsedForSb;
        

// string
sw.Restart();
var str = string.Empty;


for (int i = 0; i < iterationsCount; i++)
{
str += RandomStringGenerator.GetRandomString();
}
        

sw.Stop();
elapsedForString = sw.Elapsed;




// string builder
sw.Restart();
var sb = new StringBuilder(string.Empty);


for (int i = 0; i < iterationsCount; i++)
{
sb.Append(RandomStringGenerator.GetRandomString());
}
        

sw.Stop();
elapsedForSb = sw.Elapsed;


results.Add(iterationsCount, new TimeSpan[] { elapsedForString, elapsedForSb });
}




// Results
results.Chart(r => r.Key)
.AddYSeries(r => r.Value[0].Ticks, LINQPad.Util.SeriesType.Line, "String")
.AddYSeries(r => r.Value[1].Ticks, LINQPad.Util.SeriesType.Line, "String Builder")
.DumpInline();
}


static class RandomStringGenerator
{
static Random r;
static string[] strings;
    

public static void Setup(int testStringLength)
{
r = new Random(DateTime.Now.Millisecond);
        

strings = new string[10];
for (int i = 0; i < strings.Length; i++)
{
strings[i] = Guid.NewGuid().ToString().Substring(0, testStringLength);
}
}
    

public static string GetRandomString()
{
var indx = r.Next(0, strings.Length);
return strings[indx];
}
}