But, as long as I was testing things, I thought I would add in String.
Format and string iterpolation just to see how much worse they are.
I began by writing some very simple benchmark functions for each method, and then doing some sample runs.
What I discovered right away is that StringBuilder obliterates every other method when you're doing hundreds of appends or more.
In fact, I was honestly shocked by how much more efficient it was and it made me wonder if using longer strings would have an effect.
Early tests were just appending strings of 2 or 3 characters at a time.
I added a second append with a variable length (up to 20 characters in my test) to see what affect that had, and it evened things out a little bit, especially when doing only few total appends.
However, that made the results less obvious as to what was happening, so I then wanted to remake the test functions so that each iteration performed only one append.
The other thing I discovered quickly is that String.
Format and string interpolation have nearly identical performance in terms of speed and memory use.
So I dropped String.
Format from later tests.
And I was also surprised by how bad the performance is for interpolation.
It made me wonder how String.
Join performs.
It performs great, as it turn out.
Almost on par with StringBuilder.
Below is the final design of the test functions.
Test Functionspublic string Concat(int n, string l){ var result = ""; for (int i = 0; i < n; i++) { result += l; } return result;}public string Interpolation(int n, string l){ var result = ""; for (int i = 0; i < n; i++) { result = $"{result}{l}"; } return result;}public string StringBuilder(int n, string l){ StringBuilder sb = new StringBuilder(""); for (int i = 0; i < n; i++) { sb.
Append(l); } return sb.
ToString();}public string Join(int n, string l){ var list = Enumerable.
Range(0, n).
Select(i => l); return String.
Join("", list);}The source is available on Github if you want to check it out for yourself and see everything in context.
Medium doesn’t support tables.
To see the results, please check the original post at https://jenniferplusplus.
com/stringbuilder/ConclusionsStringBuilder is efficient at smaller scales than I thought, but it’s still not clearly an improvement over concatenation until you’re doing between 20 and 40 appends, depending on the size of the strings you’re appending.
StringBuilder is also basically pointless if the strings you’re building are not already created; the work it takes to generate them will most likely wipe out any optimization you can do to assemble the final result.
So, should you use StringBuilder?.Yes, sometimes.
It depends on what your data is like, and what you’re optimizing for.
Basically, if you have large strings that you’re concatenating only a few times, string concat may be more efficient in all criteria.
If you’re optimizing for memory, then Join has excellent memory efficiency for small strings, and comparable to StringBuilder for large ones.
In any case, I think that 40 concats is a good rule of thumb break point for where you get clear performance benefits from StringBuilder regardless of what your data looks like.
But then that brings me to the actual heart of the matter.
What are you doing that needs this kind of performance?.Look at that chart again.
All of these times are measured in nanoseconds.
That’s 1/1000 of a microsecond.
Which is 1/1000 of a millisecond.
Which is 1/1000 of a second.
Do you really want to bother over a few billionths of a second?.And so my real take-away advice here is to optimize for readability.
If performance is a real world issue, then and only then should you optimize for performance.
.