While the article is a little short, it is well written and well illustrated. Although, StringBuilder has been written about before I still see programmers using string instead of StringBuilder because it is simplier. It is good to provide more evidence as to why StringBuilder should be used instead of string.
Just because the code works, it doesn't mean that it is good code.
First off, great article. I have been telling people for years to start using stringbuilder and stop concatenating.
Your article talks about using string and stringbuilder in a loop and I often get asked the question of why use a stringbuilder if you are not looping and only want to concatenate a couple of items together. For example:
I tell them there is no reason to use a StringBuilder if you have a small set of items to concatenate together, instead use a string, and use format with that string and then give them an example like this.
Dim HtmlBody asString = String.Format("User Domain: {0}<br />", UserDomainName)
I do make sure to tell them that if you have a lot of items and the string is pretty long that you should use a stringbuilder instead so it's a little easier to follow.
The StringBuilder.AppendFormat method has to work through the format string to replace the placeholders with the specified parameters. The method will allocate an additional StringBuilder instance for each placeholder which includes a format specifier (eg: "{0:D}").
Your first example will typically be compiled as a call to String.Concat(String, String, String), which is optimized to build the string in one go, without using a StringBuilder instance. Even in the worst-case, the two String.Concat(IEnumerable) methods use a StringBuilder.
So, whilst I would prefer your second example for readability, the first is actually more efficient!
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
If you're concatenating a small number of short strings (about 4 to 8), it's faster to just concatenate them than use a StringBuilder. But obviously StringBuilder is the way to go for 10,000 strings! In the early days of .NET (v1.0) concatenating strings was slow but (for a small number of strings) the compiler has been optimised as this is quite a common activity. There are plenty of articles around that measure the performance of concatenating against using StringBuilder.
And if you use a StringBuilder, don't forget to use the constructor that sets its initial capacity as this will speed it up a bit more. From memory, the default capacity is 16 chars. Each time the string builder is increased by doubling its size, e.g. 16, 32, 64, 128..., so if you expect 10,000 4-letter words, give it an initial capacity of 40000.
I think it would be good to note that StringBuilder works by allocating an initial buffer, and each time that buffer overflows, allocating a bigger one. The difference between StringBuilder's allocations, however, and those of the repeated-string-concatenation scenario, is that each allocation is twice the size of the previous. Consequently, the worst-case total amount of memory allocated if one builds a string using StringBuilder and then calls ToString on it will be roughly five times the final size of the string (the worst case would occur when the final string would be one character longer than the space allocated for it; the buffer size would then become twice the previous allocated space (i.e. almost twice as long as the final string), all previous allocations together would roughly total the present buffer size; the final string would of course be equal to the size of the final string. Adding those things together gives a 5x multiple, which doesn't sound great, but is *bounded* and *finite*. By contrast, if one builds up a string by adding a piece at a time, 100,000 times, the total allocation will be roughly 50,000 times the size of the final string.
Submit an article or tip
Post your Blog
5ed
News 
Bug 
Joke 
Rant 
Admin 
