Way4 however would just replace Way2 by leaving out the “=” signs and your result is a single string in IL code

You’d have to run your samples in a loop (100?) and look at the profiler in that case. If interning works, it doesn’t really matter much, since you’d have 4/5 strings at most, if it’s not at work you should see ending up with 400+ ish strings

String.Format is powerful, but powerful tools often sacrifice raw speed for robust features.

String.Format is very readable, and for localization issues it’s extremely powerful. If you have a resource file that has a literal called MyFormat being:
en-US = “There are {0} cars in {1} garages.”
fr-FR = “Dans {1} garage, il est {0} auto.”
(pardon my French, just for illustration)

String.Format is also good in this manner because the culture-specific format string can have date/time, precision and other formatting which will vary culture to culture. String.Format allows the code to move from culture-hardcoded to culture agnostic and is very portable and robust at the same time.

String.Concat on the other hand is raw speed. If you can get away with it, use it.

If you have a variable number of concatenations, then a StringBuilder is the way to go.

If you need to format strings and address internationalization issues, there’s nothing better than string.format.

//;Way1

//string s1 = string.Format(”Data Source={0}; Initial Catalog={1}”, “HA”, “HA”);

//;Way2
//string s = “Data Source=”;
//s+=”HA”;
//s += “Initial Catalog=”;
//s += “HA”;

//;Way3
string[] pieces = new string[] {”Data Source={0}; “, “Initial Catalog={1}”, “HA”, “HA”};
string s1 = string.Concat(pieces);

- for a determinable end string length, the fastest method is the operation method (#1 above) for = 5

- for an undeterminable end string length, the fastest method is the operation method (#1 above) for = 7. However since dynamically sizing an array has it’s own overhead, for almost all practical purposes a null instantiated string builder is more efficient

- string.format is an interesting case because it allows you to effectively concatenate fewer strings than you would have to using another method (cf. building a string to match the format “a{0}b{1}c”), practically though it’s still the least efficient method for any situation where you aren’t formatting about 7 fewer strings than a builder would concatenate. I can think of no situation where that could reasonably occur.

This essentially matches David and Jouni Heikniemi’s findings: think about using stringbuilder at around 5-7 concats

I’m really impressed by the depth of your research and the quality of this article.

It’s clear and concise.

Thanks for the contribution!

http://www.microsoft.com/downloads/details.aspx?FamilyID=A362781C-3870-43BE-8926-862B40AA0CD0&displaylang=en

By the way, what was the application you used to profile your test code and to produce those profiling charts? Chinh

I do have an older blog post on the use of StringBuilder at http://community.bartdesmet.net/blogs/bart/archive/2005/10/04/3583.aspx – it might be an interesting read as well. Notice it’s written in a pre-.NET 2.0 manner without the use of the Stopwatch class to measure perf results.

-Bart

Normally it’ll do this till 4 string overloads before creating scenario 3 internally. (That’s what I’ve come to understand from the references on top of my article).

As a general rule if I do 3-4 concats I tend to use + operators if only for readability. Antyhing more I use a StringBuilder.

While this stuff makes sense in real performance critical scenarios, I would consider this the sort of micro profiling that yields the least performance gains in most applications.

In the future I’ll be using StringBuilder according to Jouni Heikniemi’s guidelines.

Quoted:
“If you have no idea on the resulting string size, use StringBuilder if you have at least 7 concatenations.

If you can roughly (with 30% accuracy) estimate the resulting string size, use StringBuilder if you have at least 5 concatenations.

If you can estimate the resulting string size with good accuracy, use StringBuilder if you have at least 3 concatenations.

Under no conditions is StringBuilder faster for less than 3 concatenations.

StringBuilder beats strings for 10+ concatenations in every practical situation.

The longer the strings are, the more final string size estimations will help you (but accuracy becomes more critical).”

I’ve also come to the conclusion that simply estimating the minimum size is a good start as well.

eg: I know I’m going to be appending StackTraces, so the StringBuilder I’m creating starts with an initial size of 256 or 512 (I’m using those values since the StringBuilder has 16 as default and would always be doubling them, this I’m saving out some initial doubling)

This means that two copies of your array would be allocated. I think this can be problematic for large arrays. The only benefit seems to be a pass whereby the final string size is known before final string allocation.

Contrast this with StringBuilder, where if you knew the approximate size of the resulting string, you could initialize the capacity to something large enough to hold it. Combine this with the fact that array concatenation would seem strange to me as a code reader and the solution becomes clear: Use a stringbuilder and guess the initial capacity. If you are unsure of the capacity, trace the actual length of your resulting strings and adjust.