Buffering Content

At the lowest level, Web applications are receiving data from the client browser, and formatting and sending data back. In several places during the page execution while the content is being put together, buffering pieces of the output into large pieces can be advantageous. In this section, we’ll talk about how buffering works and how to optimize for it. Some developers attempt to accomplish their own optimizations, which can ultimately work against performance, so we’ll look at when to leave well enough alone.

Use Response Buffering

ASP.NET is configured to buffer content by default. Data written back to the output is coalesced into larger chunks to avoid the performance penalties associated with sending many small pieces of content through the Web server to the client. You can send fewer TCP packets containing more data, thus reducing the overall percentage of communication overhead. Unless you have specific reasons to turn off buffering, leave it on. One of the few reasons you might consider changing the buffer attribute of the pages config setting to false is for an extremely long running request. In this case, you would need to be sure that you had a complete piece of content that could be rendered by the browser so that the user could see a visual response. It would be better to break this sort of page, which has intense processing, into multiple requests that conduct smaller pieces of work and provide status updates to the client. Consider queuing work for offline processing or pre-processing where possible.

Avoid String Concatenation

As content is built up for the client, in some cases, you’ll need to append strings to an already existing string. You probably have the inclination to write methods that build up a final self-contained piece of content and call Response.Write with the complete string. However, this tendency can actually work against performance. In addition to the small substrings, separate larger strings are also created to hold the concatenated string. The substrings in this case are really just temporary memory consumers that must be allocated, copied into the larger string, tracked, and ultimately garbage-collected. If you don’t have a compelling reason to concatenate the strings before passing them to Response.Write, don’t. Remember that ASP.NET will buffer the output, so it’s better to create the string once and pass it on to avoid the overhead of concatenation.

Loops of string concatenation are particularly destructive to performance. A single part of a string used in a loop of concatenation can end up in multiple strings that are never actually rendered. Where possible, replace the loop with iterative code or replace the concatenation with separate Response.Write calls and let ASP.NET do the buffering.

Use StringBuilder

By definition, string instances in the common language runtime are immutable. They can’t be changed. When you call an API that results in a modified string, you are really getting a new copy of the string with the change. When strings are concatenated, the original strings still exist, along with a new string that contains copies of the original strings. When code needs to concatenate strings repeatedly, use a StringBuilder object to enhance performance. Here’s a good rule of thumb: when you have six or more modifications or concatenations to a single string instance, change the code to use StringBuilder. The StringBuilder object acts more like an array of characters. Long chains of concatenation are still associated with performance costs, but the StringBuilder class is better equipped to deal with this concatenation.