Performance Metrics for the ASP Response Object, Part 2By James Greenwood
In Part 1 we examined three different tests for outputting content. In this final part we'll look at the timing results from these tests and examine the performance results using ASP.NET.
On a PIII, running Windows 2000 and IIS5 (hence ASP 3.0), the results, averaged over three trial runs, are as follows:
- Method 1: 0.534 seconds
- Method 2: 0.721 seconds
- Method 3: 4.297 seconds
As can be seen from this, the performance of context switching is greater than that of any other
technique. This is the opposite of in earlier versions of ASP, where it was common knowledge that
each context-switch was a very expensive operation. As the processing time is on the same order of
magnitude - with
Response.Write()ing code taking 50% longer, a decision has to be made
over which is more important to a company - performance, or maintainability. The author's personal
opinion is that processors are relatively cheap when compared to the extra time involved in
maintaining unstructured coding. Additionally, optimizations can generally be made in other areas
that will more than compensate for this performance hit.
The difference in performance between the first two and the third method is the big surprise. It
is easy to assume that using the
With block would speed up execution due to having a
more efficient reference to the object. This is clearly not the case, and the performance is an order
of magnitude (10x) slower than that of method 1. This kind of performance hit is generally completely
unacceptable, especially due to the small benefit that is gained in terms of maintainability.
One of the main claims about .Net is that the performance offered is vastly superior to that of traditional ASP. To test that claim, a similar piece of code can be written in ASP.Net, compiled, and run to see the execution time. The code below is the C# implementation of the algorithm used in traditional ASP above:
As can be seen from this, the functionality of a Timer can be implemented using the
TimeSpan classes. This static method of
Now in the Timer class can be
called to get the start time, and the elapsed period can be calculated by subtracting the initially
stored time to the time at the end of processing (in Ticks - a Tick being 100 nanoseconds). This value
can then be converted back to fractions of seconds by calling
When this code is compiled and executed (simply by loading the ASP.NET Web page in a browser), it can be seen that the performance claims made by Microsoft are justified, with the elapsed period being around 0.10 seconds. This is only 28% of the execution time of the fastest we could achieve from traditional ASP.
The .NET Framework contains a
StringBuilder class that was designed to allow for efficient
concatenations of strings, an expensive operation. Many developers write code that continuously builds
a string before outputting it, perhaps in a loop through the contents of a Recordset. Continually
adding onto a string is expensive, though, and the performance pitfalls are great. To learn more about
this problem and how to solve it in classic ASP, be sure to read:
- An Efficient String Concatenation Component.
While doing multiple
Response.Writes is much faster than building up a string, we can
obtain performance gains of up to 10x by using the .NET Framework
StringBuilder class in our
ASP.NET Web pages. A simple example of using this class can be seen below:
The time required to execute the above script averaged 0.09 seconds. If you attempted to build up a string with 500,000 characters, one character at a time, the running time would take much longer, on the magnitude of three full minutes!
The performance of context switching has vastly improved from earlier versions of ASP to ASP 3.0, making it more efficient than an ASP method call. As the performance of these two styles of programming are on the same scale, other factors should probably be considered when decided which technique is appropriate. This cannot generally be said for the third method, where the performance can be subjectively categorized as appalling.
ASP.Net offers an even greater performance, being between three and four times as fast at completing
the same task, and thirty to forty times faster when using the
StringBuilder class. This
is due entirely to the benefits achieved by executing compiled code. With output caching, this figure
will be even more impressive.
As with all benchmarks, this test should not be treated as a definitive comparison of techniques, it merely provides a quick metric, showing an approximate ordering of performances. Even this should not be taken out of context - the length of strings involved, the fact that only literals rather than variables and function calls were involved, and so on, should all be taken into consideration when comparing performance. Furthermore, performance alone is quite often a misleading way of determining best coding practices, it this weren't the case, all programming would still be in hand-crafted assembly-language, making use of the idiosyncrasies of the CPU, shift registers, etc.