StringBuilder sb = new StringBuilder();
sb.Append(”hello”);
sb = new StringBuilder();

Bob responds:
Presumably newing up another instance is more expensive than simply clearing the buffer of an existing one. Also, creating new instances and abandoning old ones probably means more memory fragmentation and would tend to run the garbage collector more. Can’t say that I’ve tested it, though, and one’s mileage would vary depending on usage patterns. Always remember, most of this discussion ends up not mattering all that much in terms of performance unless you’re in a tight loop with many iterations, and then, of course, it’s best to verify your assumptions with testing.

To expand it even further, in .NET 3.5 (not sure which version it was introduced) you can create an expanded method as such:

public static void Clear(this StringBuilder stringBuilder)
{
stringBuilder.Length = 0;
stringBuilder.Capacity = 16;
}

now when you create your stringbuilder you can call it normally. For example:
StringBuilder sb = new StringBuilder();
sb.Clear();

Bob responds:

To this end — 3.5 introduces a Clear() method anyway, and while it’s not documented what, if anything it does to the Capacity value, if it leaves it alone, creating an extension method that sets it to a specific value might be a useful enhancement.

Just because it’s small doesn’t mean it doesn’t matter (or at least that’s what my gf tells me).

If you save 16 bytes or 2MB, it may seem small until you multiply it by the number of users.

Consider the user count of say Mysp@ce or M$ or the NY Stock Exchange.

Bob responds: There is a balance between thrashing and a stable state to consider. I am simply saying that with a single StringBuilder, if you expect to construct strings of say 50 to 100 bytes, with the majority toward the top end, set an initial capacity of 100 and leave it alone. Destroy the StringBuilder when you are done with it. This is better and simpler in almost all real world cases than tamping the capacity back down, unless actual testing reveals a clear advantage, which I predict it won’t.

someStringBuilder.length = 0 ;

does not reduce the capacity as expected.

If using .net 2.0 follow your ‘length = 0 ‘ with .capacity = 0;
like this:

someStringBuilder.length = 0;
someStringBuilder.capacity = 0;

Together Everyone Achieves More

Bob responds: Yes, length and capacity are two separate issues. The default initial capacity is 16, the default initial length is zero. The string grows until it reaches the capacity and triggers an expansion. So if your objective is to reduce the buffer size you have to set capacity separately. However I would never set the capacity to zero. That guarantees that on future Append() calls you will have at least one auto-expansion of the buffer — an expensive and potentially memory-fragmenting operation. Zero should not be a legal value for Capacity. Set Capacity to at least 1 or the minimum length of the string you expect to create, whichever is larger.

M$ says in article on MSDN:
Notes to Implementers:
The default capacity for this implementation is 16, and the default maximum capacity is Int32..::.MaxValue.

http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx

Bob responds: In general, you will clear the buffer in order to re-use the StringBuilder, likely to construct another string of similar size. Nothing is to be gained by shrinking and re-growing the capacity (re-expansion is expensive too) unless you won’t be using the StringBuilder at all, in which case the entire StringBuilder should go out of scope anyway. In addition, garbage collection is non-deterministic and you have only rough control over it. If you must obsess over managing a system that is carefully designed and tuned to manage itself just fine in the vast majority of real-world scenarios, your concern is likely misplaced. You should be more concerned about the design of your object graph. Finally keep in mind that you can very often set the initial capacity when the StringBuilder is constructed. You can set the capacity for the expected use in such a way that the buffer will auto-expand very little if at all during use, thus minimizing memory fragmentation.

Thanks again!

Bob responds: No, because the point isn’t to save memory, it’s to clear a string builder for re-use in a way that is simpler. If you need to clear it, you need to clear it. In addition, you beg the question, “saves anything in comparison to what?” Saves time vs newing up a new StringBuilder? Probably. Saves time vs the other methods I mentioned? Very likely. Enough of either to matter? Depends on the particular situation and the mix of factors such as how much other work is being done within the loop, the size of the strings being manipulated, and so on. But I subscribe to the principle that the drop-dead simplest way of doing any one thing tends to be the very best way of doing that thing, even if the only obvious benefit is elegant, self-evident code.

If you mean, does setting the length to zero clear the buffer and free any memory … I doubt it. A StringBuilder has a default initial capacity of 16 byes (you can override the default with one of the overloaded constructors). If the string exceeds the capacity, the internal buffer is doubled in size until it’s big enough. I’m sure that setting the length to zero simply makes the buffer re-usable, and doesn’t shrink it. However, in most cases, freeing up memory would not be a net win because as the new string is built, the buffer would have to be re-expanded, which is a fairly expensive operation (and for all I know, tends to fragment memory).