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!