I know there are plenty of people out there that will disagree with me, but I urge you to not use the .NET StringBuilder class in 99% of the cases you would be tempted or recommended to do so. Here is why:
The StringBuilder class does perform better than basic string concatenation. However, it is really only noticable with ridiculous string lengths. For example, if you are concatenating a SQL statement together for a statement that has less than 100 columns, the difference will be negligible. Slamming 10,000 strings puts StringBuilder as the clear winner in time as it will shave about 2 tenths of a second off of your processing time.
I ran some tests, and comparing a basic concatenation to using a string builder to slam together 100 “A” characters is a wash. Sometimes the StringBuilder even took longer. At 1000 characters, StringBuilder was a slight winner. Of course this amounted to about 20 milliseconds on average. Unless you are doing a lot of concatenation, this won’t really be a noticable difference… and we are already talking about 1000 operations!
Below are the results of my test (click on thumbnail) that were not posted on my original rant, but have since been added to this post. You can see the strings of varying lengths I used as well as the number of concatenation operations that were performed on each. The ”Total String Length” column represents the overall lentgh of the resulting string after all operations are complete.
As you can see, nothing short of millions of resulting characters or tens of thousands of concatenation operations ends up in response time that is over 1 second. Looking at a typical operation in my world such as concatenating a SQL statement together, we would be dealing with something like rows 9 and 10 of the above table. These tests took the string “AND COLUMN1 = ‘VALUE’” and concatenated it together 1,000 times. Although this would still be a ridiculously long SQL statement (and probably perform horribly ), the difference between using a StringBuilder (193 ms) and simple concatenation (214 ms) is only 41 milliseconds difference. Yes, I realize that is about 20%, but again, if you are doing this concatenation many times, you may need to write your own custom object to meet your true needs. Another interesting find is that the # of operations seems to have a much bigger impact than the overall length of the string itself.
Yes, it is terrific that somebody at Microsoft realized working with a collection (string) of hundreds of thousands of members (characters) will not perform will if it is not indexed. No kidding! But who in their right mind will be dealing with strings of 500,000+ characters? If you are doing that, then you probably need to rethink your approach to solving the problem at hand.
Because of the added complexity, additional lines of code, developer ramp-up possibility (for those not exposed to the class or .NET) and risk of change in future versions of .NET, I say you should not use the StringBuilder class… unless, of course, you find yourself needing to deal with that all to common million character string
Filed under: C#, Development, Performance | 6 Comments »