stringbuilder performance questions

[pantagruel]

Hi,

It is generally stated that stringbuilder should be used instead of
just concatenating strings with the plus operator.

That's fine enough what I'm wondering in cases I have:

String S = "hello" + World;

Does it make any sense to use Stringbuilder in a case like the above,
where the concatenation only takes place in the declaration of the
variable, as opposed to :

String S = "";

S = "hello" + World;
S = S + " from me";
where I can see the obvious benefits.

Aside from concatenation does StringBuilder provide performance
benefits if I am overwriting the value of the String at different
places, for example during a loop? I suppose the answer there would be
yes because the size of the string is thus dynamically set in each
iteration, but is StringBuilder the correct solution for this or
should I use some other tool.

 

[Jon Skeet [C# MVP]]

It is generally stated that stringbuilder should be used instead of
just concatenating strings with the plus operator.

Well, it entirely depends on the situation.

That's fine enough what I'm wondering in cases I have:

String S = "hello" + World;

Does it make any sense to use Stringbuilder in a case like the above,
where the concatenation only takes place in the declaration of the
variable, as opposed to :

String S = "";

S = "hello" + World;
S = S + " from me";
where I can see the obvious benefits.

In fact, with just a couple of concatenations you'd probably still not
get a performance benefit from using StringBuilder. As ever with
performance issues, "it depends".

Aside from concatenation does StringBuilder provide performance
benefits if I am overwriting the value of the String at different
places, for example during a loop? I suppose the answer there would be
yes because the size of the string is thus dynamically set in each
iteration, but is StringBuilder the correct solution for this or
should I use some other tool.

If you don't need intermediate values and you're looping round a
reasonable number of times (or an unknown number) then StringBuilder
is the way to go.

See http://pobox.com/~skeet/csharp/stringbuilder.html for more
information.

Jon

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


This has been discussed ad nauseam, if you check the archives you will see
that in cases like the one you describe there is no diffeence.
The real difference is when you use it in a loop.

But again, look into the archives.

 

[Samuel R. Neff]

Concatenation within a single line is better done with the + operator
instead of with StringBuilder. StringBuilder is best when
concatenating across lines, especially in loops and such. Especially
if you're overwriting portions of the text, then StringBuilder is
best.

Other things to keep in mind is pre-initialize a good size for your
StringBuilder if you're building lots of strings, especially if
they're similar in size. It's better to have originally built a
StringBuilder that had too high of a capacity than to have to expand
it several times, ex

StringBuilder builder = new StringBuilder(64);

if you're expecting to make strings between 32 and 64 chars.

Another thing to keep in mind is that String.Join() has even better
performance than StringBuilder so if you're essentially joining
together a bunch of lines, consider using that (but don't contort your
situation into using String.Join unnecessarily).

HTH,

Sam

 

[Alun Harford]

I feel this whole thread is a little silly. Generally readability is
better than marginal performance gains. StringBuilder is probably the
most overused class in the whole framework.

However,

Concatenation within a single line is better done with the + operator
instead of with StringBuilder. StringBuilder is best when
concatenating across lines, especially in loops and such. Especially
if you're overwriting portions of the text, then StringBuilder is
best.

Other things to keep in mind is pre-initialize a good size for your
StringBuilder if you're building lots of strings, especially if
they're similar in size. It's better to have originally built a
StringBuilder that had too high of a capacity than to have to expand
it several times, ex

StringBuilder builder = new StringBuilder(64);

Almost certainly far too small. There is a performance hit from creating
the StringBuilder. If you're just appending, you're probably better
doing it naively in this case (unless you can only append a single char
at a time, I guess). If you're doing lots of manipulation, you're better
off manipulating a stackalloc array of chars for something so very small.

Also, if you're trying to get performance, 64 chars is probably a bad
idea. Strings in .NET are null terminated for interop purposes, so the
size of the string will not be a multiple of 4 bytes - that's just
wasted space in your cache line!

Alun Harford

 

[Arne Vajhøj]

I feel this whole thread is a little silly. Generally readability is
better than marginal performance gains. StringBuilder is probably the
most overused class in the whole framework.

It is probably case #1 in any C# optimization book
for beginner, so every beginner "knows" that the key
to good performance in C# is using StringBuilder instead
of String concatenation.

Arne

 

[Rad [Visual C# MVP]]

I feel this whole thread is a little silly. Generally readability is
better than marginal performance gains. StringBuilder is probably the
most overused class in the whole framework.

However,


Almost certainly far too small. There is a performance hit from creating
the StringBuilder. If you're just appending, you're probably better
doing it naively in this case (unless you can only append a single char
at a time, I guess). If you're doing lots of manipulation, you're better
off manipulating a stackalloc array of chars for something so very small.

Also, if you're trying to get performance, 64 chars is probably a bad
idea. Strings in .NET are null terminated for interop purposes, so the
size of the string will not be a multiple of 4 bytes - that's just
wasted space in your cache line!

Alun Harford

While true for a small number of concatenations, when you are concatenating
large number of strings there is a difference in several orders of
magnitude

 

[Alun Harford]

While true for a small number of concatenations, when you are concatenating
large number of strings there is a difference in several orders of
magnitude

Indeed. But if the performance of your application is limited by how
fast you can concatenate strings together, then things are very wrong.

Alun Harford

 

[Samuel R. Neff]

Indeed. But if the performance of your application is limited by how
fast you can concatenate strings together, then things are very wrong.

Alun Harford

Alun,

There is no reason to ignore well-known performance tips just because
the net effect is small in many cases. It's always good to which
techniques perform better than others and do things the right way in
the first place.

I'm really amazed you're arguing against using StringBuilder or
teaching someone best practices.

Sam

 

[Peter Duniho]

There is no reason to ignore well-known performance tips just because
the net effect is small in many cases. It's always good to which
techniques perform better than others and do things the right way in
the first place.

I'm really amazed you're arguing against using StringBuilder or
teaching someone best practices.

I don't think he is. I think he's arguing that there are other concerns
than just performance. In many situations, using a string with
concatenation may be more readable or maintainable than using a
StringBuilder, and if those are situations in which it's known that the
concatenation will never be a noticable performance problem, then it makes
sense to use concatenation instead.

He's also quite right in pointing out that if you think you need to
pre-initialize the StringBuilder with some fixed constant, that "64" is
way too small to be useful (unless, of course, you have reason to believe
that your strings will _never_ exceed 64 characters).

Now, I think he may be overstating the relative likelihoods of the
comparative scenarios. Some applications may spend a lot of time building
new strings from numerous small pieces. While the majority of
applications may not have this characteristic, that doesn't mean that
there aren't a good number of correct implementations that would require
that behavior. So if anything, I would disagree with the statement that
"things are very wrong" if an application needs to use StringBuilder.

Just knowing that an application is bounded by its string concatenation
behavior doesn't tell you anything about whether that application is
"wrong" or "right".

If anything, he's simply guilty of making broad, unfounded
generalizations. But otherwise, the basic gist of his advice is sound:
just because StringBuilder performs better in the unbounded case, that
doesn't mean that it's actually the right thing to use all of the time.

Pete

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I feel this whole thread is a little silly. Generally readability is better
than marginal performance gains. StringBuilder is probably the most
overused class in the whole framework.

We all agree that for a small number of concats the difference is not
noticeable. When you are doing it in a loop the improvements are real.

A similar situation happen with boxing/unboxing. Doing it for one value
represent no change. doing it in a loop like
foreach(object o ....
if ( 1 == (int)o

Is a BIG difference

 

[Alun Harford]

There is no reason to ignore well-known performance tips just because
the net effect is small in many cases.

[/QUOTE]

The use of StringBuilder decreases performance over naive concat in a
large number of cases I have seen it used.

Far too often, I've seen:

StringBuilder sb = new StringBuilder();
sb.Append("Foo ");
sb.Append(myVar.ToString());
sb.Append(" bar ");
sb.Append(someMethod());
etc(sb);
return sb.ToString();

Eugh! *Far* slower than a concat, and far less clear.

In some languages, performance is often really important. Javascript is
a good example; it's an interpreted language and you're trying to do
interesting real-time stuff on somebody's 100MHz PC.

In Javascript, it's quite common to see loops like this:

for(var i = 0, l = myArray.length; i < l; i++)
{
doSomething();
}

It's faster - you don't have to get myArray.length more times than you
need to.

I strongly suspect this would also be faster in C# (the JIT compiler
might optimize it to the same code for arrays if it's good, but it
couldn't do Lists).
It's not a good idea - performance is rarely an issue in C#.

Generally, I think it's best to optimize for maintainability. The
majority of programs spend >95% of their CPU time in a few methods - you
only need to optimize for speed in those methods, if at all.

I don't think he is. I think he's arguing that there are other concerns
than just performance. In many situations, using a string with
concatenation may be more readable or maintainable than using a
StringBuilder, and if those are situations in which it's known that the
concatenation will never be a noticable performance problem, then it
makes sense to use concatenation instead.

He's also quite right in pointing out that if you think you need to
pre-initialize the StringBuilder with some fixed constant, that "64" is
way too small to be useful (unless, of course, you have reason to
believe that your strings will _never_ exceed 64 characters).

Now, I think he may be overstating the relative likelihoods of the
comparative scenarios. Some applications may spend a lot of time
building new strings from numerous small pieces. While the majority of
applications may not have this characteristic, that doesn't mean that
there aren't a good number of correct implementations that would require
that behavior.

StringBuilders get abused both as a 'fast' concat, and a pseudo-stream.

Simple programs that manipulate strings should generally work on
streams. More complex programs should generally parse the string into a
more sensible internal structure and work on that instead.

Nice UNICODE strings are lovely for humans, but about the worst possible
choice of internal data type.

It doesn't help that people who havn't quite figured this out yet get
told "it's okay - just use a StringBuilder instead"

So if anything, I would disagree with the statement that
"things are very wrong" if an application needs to use StringBuilder.

Sometimes, you have to maintain code that should have got the author
many years in jail. Perhaps it's doing some complicated mathematics by
constructing an huge SQL query to send to a database server and getting
the result back as a scalar. (Yes, people really do write code like this)

If it needs to be more performant, you might profile it and find that
it's bound by the speed it can concat strings together in a particular
method. If it doesn't make economic sense to do a total rewrite, a quick
and dirty solution would be to change that method to use a StringBuilder.

There are few good reasons to use a StringBuilder outside of this
scenario (although I will admit they do exist - as do good reasons to
use TypedReferences, try{}IL-fault{} blocks, VB.NET, etc).

Alun Harford

 

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:

We all agree that for a small number of concats the difference is not
noticeable. When you are doing it in a loop the improvements are real.

A similar situation happen with boxing/unboxing. Doing it for one value
represent no change. doing it in a loop like
foreach(object o ....
if ( 1 == (int)o

Is a BIG difference

I think there's a significant difference between boxing and string
concatenation though. If you've got an unboxing operation in a loop,
you get a reasonably fixed performance penalty per iteration of the
loop. In other words, as the length of the loop increases, the time
spent will grow linearly.

With string concatenation, as the string gets larger it takes longer to
copy each time, so you get an O(n^2) problem (very roughly). It's that
kind of thing that makes me *much* more concerned about getting string
concatenation wrong than including an unnecessary boxing operation.

I suspect it's quite rare for boxing to turn into an actual bottleneck
- whereas string concatenation could do so very easily.

 

[Peter Duniho]

[...]
StringBuilders get abused both as a 'fast' concat, and a pseudo-stream.

When they are used to concatenate small strings, and when they are used in
situations that are really streaming data, I'd agree. But that doesn't
mean that a program using StringBuilder is necessarily written wrong. It
just means that _some_ programs using StringBuilder are written wrong.

Simple programs that manipulate strings should generally work on streams.

Why? Why abstract out when the program is _always_ operating on a string?

I can see the value in writing general-purpose code that can deal with a
variety of streaming types. But if you know it's a string, that it's
always going to be a string, and you are manipulating a string (as opposed
to streaming data), why complicate the code by introducing the idea of a
stream?

More complex programs should generally parse the string into a more
sensible internal structure and work on that instead.

I don't understand this at all. Parsing is about reading a string.
StringBuilder is about writing a string. Arguing that a program ought to
do the former rather than the latter seems like a non sequitur to me.

Nice UNICODE strings are lovely for humans, but about the worst possible
choice of internal data type.

How so? It seems like a perfectly appropriate data type when what you're
dealing with are Unicode strings (note actual spelling of "Unicode").

It doesn't help that people who havn't quite figured this out yet get
told "it's okay - just use a StringBuilder instead"

A complete discussion of string manipulation would cover some of the
specifics you're talking about, agreed. But sometimes all that's needed
is to point out that StringBuilder is appropriate when repeatedly
concatenating data onto a string in a loop, and that straight string
concatenation is more appropriate for bounded manipulation.

Why go into all those other details? They just make it harder to make the
basic point, because they are distracting from the basic point.

Sometimes, you have to maintain code that should have got the author
many years in jail. Perhaps it's doing some complicated mathematics by
constructing an huge SQL query to send to a database server and getting
the result back as a scalar. (Yes, people really do write code like this)

So? How is that relevant to the statement that an application that needs
to use StringBuilder is "very wrong"? How does it justify that statement?

There are lots of bad ways to write code. I've seen plenty of them. That
doesn't mean that there's never any reason for an application to need to
use StringBuilder.

There are a handful of things in .NET that IMHO they just should have left
out altogether. They encourage very poor programming design and
techniques. But I just don't see the StringBuilder class being in that
category.

If it needs to be more performant, you might profile it and find that
it's bound by the speed it can concat strings together in a particular
method. If it doesn't make economic sense to do a total rewrite, a quick
and dirty solution would be to change that method to use a StringBuilder.

Given only the information you mention with respect to profiling, how can
you even assert that a rewrite would be beneficial, never mind necessary?
It's entirely possible that changing the code to use a StringBuilder is
not only a quick change, but a perfectly appropriate one (i.e. not "dirty"
at all).

There are few good reasons to use a StringBuilder outside of this
scenario (although I will admit they do exist - as do good reasons to
use TypedReferences, try{}IL-fault{} blocks, VB.NET, etc).

Well, that looks to me like you just agreed that it's wrong to
characterize (as you did earlier) an application as "very wrong" just
because it needs to use StringBuilder. Beyond that, I still would
disagree that the need to use StringBuilder is anywhere near as esoteric
as the need for the other things you mention (not counting VB.NET...not
sure why you threw that in there).

Pete

 

[Alun Harford]

[...]
StringBuilders get abused both as a 'fast' concat, and a pseudo-stream.

When they are used to concatenate small strings, and when they are used
in situations that are really streaming data, I'd agree. But that
doesn't mean that a program using StringBuilder is necessarily written
wrong. It just means that _some_ programs using StringBuilder are
written wrong.

Simple programs that manipulate strings should generally work on streams.

Why? Why abstract out when the program is _always_ operating on a string?

I can see the value in writing general-purpose code that can deal with a
variety of streaming types. But if you know it's a string, that it's
always going to be a string, and you are manipulating a string (as
opposed to streaming data), why complicate the code by introducing the
idea of a stream?

A stream is a significantly simpler concept.

I don't understand this at all. Parsing is about reading a string.
StringBuilder is about writing a string. Arguing that a program ought
to do the former rather than the latter seems like a non sequitur to me.

If you have it in your own format internally and want to write that to
some output, this is exactly the time to use a stream. Then you can just
pass your stream around and your internal classes don't have to know
where they're outputting to, etc.

How so?

Normally you have more information about what those strings represent,
how they're manipulated, etc.

A complete discussion of string manipulation would cover some of the
specifics you're talking about, agreed. But sometimes all that's needed
is to point out that StringBuilder is appropriate when repeatedly
concatenating data onto a string in a loop, and that straight string
concatenation is more appropriate for bounded manipulation.

I've seen plenty of StringBuilder usage to construct the message for an
exception. Perhaps I'm optimistic, but I'd rather programmers were
competent, or at least willing to read the "complete discussion".

Why go into all those other details? They just make it harder to make
the basic point, because they are distracting from the basic point.

Because programming is about the details. Bugs occur when a programmer
fails to consider the details, and instead chooses to only look at the
"basic point".

So? How is that relevant to the statement that an application that
needs to use StringBuilder is "very wrong"? How does it justify that
statement?

Erm... this is me trying to construct a scenario where a StringBuilder
is a good idea.

There are lots of bad ways to write code. I've seen plenty of them.
That doesn't mean that there's never any reason for an application to
need to use StringBuilder.

There are a handful of things in .NET that IMHO they just should have
left out altogether. They encourage very poor programming design and
techniques. But I just don't see the StringBuilder class being in that
category.


Given only the information you mention with respect to profiling, how
can you even assert that a rewrite would be beneficial, never mind
necessary? It's entirely possible that changing the code to use a
StringBuilder is not only a quick change, but a perfectly appropriate
one (i.e. not "dirty" at all).

I'd consider refactoring code and leaving the huge WTF in the middle of
it to be "dirty". Sometimes it's commercially necessary, but it's not nice.

Well, that looks to me like you just agreed that it's wrong to
characterize (as you did earlier)

I think you need to re-read exactly what I wrote.

an application as "very wrong" just
because it needs to use StringBuilder. Beyond that, I still would
disagree that the need to use StringBuilder is anywhere near as esoteric
as the need for the other things you mention (not counting VB.NET...not
sure why you threw that in there).

Well really just VB.NET without strong typing turned on... I think
that's an 'interesting' part of .NET.

Alun Harford

 

[Peter Duniho]

A stream is a significantly simpler concept.

Not if the underlying design of the code isn't stream-oriented, it's not.
Adding a stream to code that's not inherently related to a stream is a
complication, not a simplification.

If you have it in your own format internally and want to write that to
some output, this is exactly the time to use a stream.

So what? If you don't, then it's not. Unless you are saying that it's
always the case that you have your own format internally and want to write
that to some output, I don't see how this is at all relevant to the
question at hand.

Are you saying that it's always the case that you have your own format
internally and want to write that to some output?

[...]

How so?

Normally you have more information about what those strings represent,
how they're manipulated, etc.

"Normally"? Sorry, but I don't buy that. What's "normal"? In a program
that does a lot of string manipulation, but where the strings are nothing
more than just strings, you don't "have more information about what those
strings represent".

I don't disagree that if you have that information, it's useful to use
it. But I don't see where you think you can assert that all programs have
that information, or that if they don't that the program is thus
necessarily "very wrong".

Use the right tool for the job. Sometimes StringBuilder isn't the right
tool. But sometimes it is.

I've seen plenty of StringBuilder usage to construct the message for an
exception. Perhaps I'm optimistic, but I'd rather programmers were
competent, or at least willing to read the "complete discussion".

I've never seen a statement from a reliable source (i.e. one of the
regulars here who generally post on the topic) that suggests that using a
StringBuilder for concatenating a fixed number of strings would be
desirable. There's never been a discussion like this that should have led
to someone using StringBuilder to construct a message for an exception
(except, of course, in situations where that message includes a large
number of strings retrieved from some source and concatenated inside a
loop...I'd say that'd be a good example of how not to construct a message
for an exception, but it's certainly a good place to use a StringBuilder).

Because programming is about the details. Bugs occur when a programmer
fails to consider the details, and instead chooses to only look at the
"basic point".

You are misinterpreting the basic point. See my previous paragraph. I've
never seen the "basic point" presented in a way that should lead to the
things you describe.

Erm... this is me trying to construct a scenario where a StringBuilder
is a good idea.

I don't think it's necessary to invoke "code that should have got the
author many years in jail" in order to justify the use of the
StringBuilder class. Doing so only further implies that using the
StringBuilder is a bad thing. I realize that does align with your goal
here, but it's circular logic. You can't legitimately use a contrived
scenario that carries the implication that using the StringBuilder is a
bad thing as some sort of proof that using the StringBuilder is a bad
thing.

If you're going to come up with an example where a StringBuilder is a good
idea, come up with one that's part of normal, well-designed,
well-implemented code. Of course, if you do that, your point falls
apart. But the fact that you can come up with examples of bad code where
StringBuilder is useful doesn't really relate to this discussion. I'm not
talking about StringBuilder only being useful in bad code.

[...]

Given only the information you mention with respect to profiling, how
can you even assert that a rewrite would be beneficial, never mind
necessary? It's entirely possible that changing the code to use a
StringBuilder is not only a quick change, but a perfectly appropriate
one (i.e. not "dirty" at all).

I'd consider refactoring code and leaving the huge WTF in the middle of
it to be "dirty". Sometimes it's commercially necessary, but it's not
nice.

Who said anything about "leaving the huge WTF in the middle of it"? All
you asserted was that profiling found the code is bounded by the speed it
can concatenate strings.

I think you need to re-read exactly what I wrote.

Where? Did you not write "I will admit they [good reasons to use a
StringBuilder] do exist?" I don't see how you can write that, and yet at
the same time assert that any program that uses StringBuilder is de facto
"very wrong".

Pete

 

[Samuel R. Neff]

The use of StringBuilder decreases performance over naive concat in a
large number of cases I have seen it used.

Far too often, I've seen:

StringBuilder sb = new StringBuilder();
sb.Append("Foo ");
sb.Append(myVar.ToString());
sb.Append(" bar ");
sb.Append(someMethod());
etc(sb);
return sb.ToString();

Eugh! *Far* slower than a concat, and far less clear.

Replacing "+" with StringBuilder when the concatentation can be done
in one or two lines is not efficient.. that's been stated many times,
in this thread, and you and I have both said that. Nobody is arguing
that StringBuilder should be used in that situation.

There are two situations what I would normally expect to see
StringBuilder and where I often see "+=" unnecessarily.

One is when the string concatenation is conditional, as in

StringBuilder sql = new StringBuilder(1024);
sql.Append("SELECT * FROM x ");

if (whereClause != null) {
sql.Append("WHERE " + whereClause);
}

sql.Append(" ORDER BY a");

That could be done with += or StringBuilder. SB is faster and IMO
more readable. The net effect is of course small, there are only
three concatenations. But if we all know tha SB is faster in this
situation, why not use it, even though the net effect is small?

The other common scenario is loops, and I hope we all agree that SB is
the best choice when concatenating strings within a loop.

StringBuilders get abused both as a 'fast' concat, and a pseudo-stream.

Simple programs that manipulate strings should generally work on
streams. More complex programs should generally parse the string into a
more sensible internal structure and work on that instead.

I don't understand this at all. Why use a Stream class when your
purpose is writing strings? Which class would you recommend?
StringWriter? That's just a wrapper around StringBuilder with the
TextWriter API anyways.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

 

[Alun Harford]

Replacing "+" with StringBuilder when the concatentation can be done
in one or two lines is not efficient.. that's been stated many times,
in this thread, and you and I have both said that. Nobody is arguing
that StringBuilder should be used in that situation.

There are two situations what I would normally expect to see
StringBuilder and where I often see "+=" unnecessarily.

One is when the string concatenation is conditional, as in

StringBuilder sql = new StringBuilder(1024);
sql.Append("SELECT * FROM x ");

if (whereClause != null) {
sql.Append("WHERE " + whereClause);
}

sql.Append(" ORDER BY a");

Well there are two things wrong with this in my view:

1) I want to supply:
whereClause = "1=1; DROP TABLE somethingImportant; --"

2) It's much faster and (IMO) clearer to do:

string sql =
"SELECT * FROM x "
+ (whereClause != null ? ("WHERE " + whereClause) : "")
+ " ORDER BY a";

As an aside, if I can produce a slightly different string, I could make
it even clearer with:

string alwaysTrue = "1=1";
string sql =
"SELECT * FROM x WHERE" +(whereClause ?? alwaysTrue)+ " ORDER BY a";

That could be done with += or StringBuilder. SB is faster and IMO
more readable. The net effect is of course small, there are only
three concatenations.

There is only one in either of the above examples.

But if we all know tha SB is faster in this
situation

Really? On my machine:

10000000 times your way : 6850ms
10000000 times my way : 2785ms

, why not use it, even though the net effect is small?

The other common scenario is loops, and I hope we all agree that SB is
the best choice when concatenating strings within a loop.

Not unless you actually need the performance increase. As you can see
from the numbers above, we're talking about insignificant amounts of CPU
time for a few concats or a StringBuilder.

You're much better off using the one that is clearer.

I don't understand this at all. Why use a Stream class when your
purpose is writing strings? Which class would you recommend?
StringWriter? That's just a wrapper around StringBuilder with the
TextWriter API anyways.

No. You want to avoid writing huge strings to memory where possible.
Sometimes, you can't avoid it, but more often you can.
Just write the data out to the stream that wants it.

A useful pattern for such things is to make a class that takes a stream,
makes a StreamWriter, and writes to that.

Alun Harford

 

[Bill Butler]

There are two situations what I would normally expect to see
StringBuilder and where I often see "+=" unnecessarily.

One is when the string concatenation is conditional, as in

StringBuilder sql = new StringBuilder(1024);
sql.Append("SELECT * FROM x ");

if (whereClause != null) {
sql.Append("WHERE " + whereClause);
}

sql.Append(" ORDER BY a");

That could be done with += or StringBuilder. SB is faster and IMO
more readable. The net effect is of course small, there are only
three concatenations. But if we all know tha SB is faster in this
situation, why not use it, even though the net effect is small?

"We" don't know anything of the sort.
I suggest you write a quick test of your assumption.

You might be surprised.