Cool StringBuilder Tip

One of the great things about the StringBuilder is it's ability to dynamically resize itself for situations where it is dealing with large strings. It was very helpful in building GenX.NET, especially since I wasn't always going to be writing to the file system anymore. Back in the 2.0 days, each time I loaded up a new line, I wrote it to the file system, so performace wasn't really a factor. Now it is. The problem is, however, that this dynamic resizing can sometimes come at a performance hit IF you are adding to your string beyond 1000x.

Enter StringBuilder.EnsureCapacity(Integer)

For GenX.NET, it is quite conceivable that the StringBuilder may append new data over a million times. Well, I want to make sure that it resizes itself as few times as possible. So, before I output any data, I cycle thru the Tables, Rows, and Columns collections of the DataSet, and get a total cell count. Then, I multiply that number by 30, and I have a fairly rough approximation of how much data the StringBuilder will be holding when finished. This saves me from most of the resizing that will take place on large DataSets.

What did it do for performance? Well, small files are returned almost instantaneously. Larger files are generated in almost half the time it took before I added that simple algorithm. I'm sure it will definitely have an effect when the server is under a heavier load too.

So there you have it. StringBuilders run faster if you call .EnsureCapacity first.

2 Comments

  • And you think cycling through your tables is less time consuming than a realloc? :)

  • As I said, the performance speaks for itself. In my test it's 60% faster than before I added the algorhithm.





    Which is more resource-intensive, exponentially enlarging your memory space, or doing a quick loop?





    Hey, besides that, the DataSet doesn't have a "FieldCount" property, but the DataReader sure does. Therefore, it is only run some of the time.

Comments have been disabled for this content.