Improving string handling performance in ASP programs

Program | performance | string

Brief Introduction
　　
When writing an ASP page, the developer actually creates a formatted text stream that is written to the Web client through the Response object provided by the ASP. There are a number of ways to create this text stream, and the method you choose will have a significant impact on the performance and scalability of your WEB application. Many times, when I helped clients optimize the performance of their WEB applications, it was found that one of the more effective ways to change the way HTML streams were created. This article will introduce several common techniques and test their impact on the performance of a simple ASP page.
　　
　　 ASP Design
　　
Many ASP developers follow good software engineering principles and modularize their code as much as possible. This design typically uses a number of include files that contain functions that are formatted for a particular discontinuous part of the page. The string output of these functions, usually the HTML form code, creates a complete page from a variety of combinations. Some developers have improved this approach by moving these HTML functions into Visual Basic COM components, hoping to take full advantage of the extra performance that has been provided by compiled code.
　　
Although this design approach is good, the method used to create strings that make up these discrete HTML code components will have a significant impact on the performance and scalability of the Web site, regardless of whether the actual operation is performed in an ASP include file or in a Visual Basic COM component.
　　
　　 string concatenation
　　
Take a look at the code snippet for the following writehtml function. The parameter named data is just an array of strings that contain some data to be formatted as a table structure (for example, data returned from a database).
　　
Function writehtml (Data)
Dim Nrep
For nrep = 0 to 99
SHTML = SHTML & vbCrLf _
& "<TR><TD>" & (Nrep + 1) & "</TD><TD>" _
& Data (0, Nrep) & "</TD><TD>" _
& Data (1, nrep) & "</TD><TD>" _
& Data (2, Nrep) & "</TD><TD>" _
& Data (3, Nrep) & "</TD><TD>" _
& Data (4, Nrep) & "</TD><TD>" _
& Data (5, Nrep) & "</TD></TR>"
Next
writehtml = SHTML
End Function
　　
This is a common way for many ASP and visual Basic developers to create HTML code. The text contained in the SHTML variable is returned to the calling code, which is then written to the client using Response.Write. Of course, this can also be expressed as a similar code for embedding pages that do not contain writehtml functions directly. The problem with this code is that the string data type (BSTR or basic string) used by ASP and visual Basic cannot actually change the length. This means that each time the string length changes, the original representation of the string in memory is corrupted, and a new representation is created that contains the new string data: This increases the amount of memory allocated and the allocation of memory. Of course, ASP and visual Basic have solved this problem for you, so the actual overhead is not immediately apparent. Allocating and releasing memory requires basic Run-time code to unlock individual locks, and therefore requires significant overhead. This problem becomes particularly noticeable when strings become large and large chunks of memory are allocated and unassigned quickly and continuously, as they would appear during a large string connection. Although this problem has little impact on single-user environments, it can cause serious performance and scalability problems in a server environment, such as an ASP application running on a WEB server.
　　
Let's go back to the code snippet above: How many string assignment operations do you want to perform in this code? The answer is 16. In this case, each application of the "&" operator will cause the string that the variable SHTML refers to be corrupted and recreated. As mentioned earlier, string allocation is expensive and increases as the string increases, so we can improve on this code.
　　
　　 Quick Solution
　　
There are two ways to mitigate the effect of string concatenation, the first of which is to try to reduce the size of the string being processed, and the second is to try to reduce the number of string assignment operations performed. See the revised version of the writehtml code shown below.
　　
Function writehtml (Data)
　　
Dim Nrep
　　
For nrep = 0 to 99
SHTML = SHTML & (vbCrLf _
& "<TR><TD>" & (Nrep + 1) & "</TD><TD>" _
& Data (0, Nrep) & "</TD><TD>" _
& Data (1, nrep) & "</TD><TD>" _
& Data (2, Nrep) & "</TD><TD>" _
& Data (3, Nrep) & "</TD><TD>" _
& Data (4, Nrep) & "</TD><TD>" _
& Data (5, Nrep) & "</TD></TR>")
Next
　　
writehtml = SHTML
　　
End Function
　　
At first glance, it may be difficult to see the difference between this code and the previous code example. In fact, this code simply adds parentheses outside the SHTML = sHTML & content. This actually reduces the size of the strings processed in most string concatenation operations by changing the precedence order. In the original code example, the ASP compiler looks at the expression to the right of the equal sign and evaluates it from left to right. As a result, 16 connection operations are performed for each repetition, and these operations are performed for the ever-increasing sHTML. In the new version, we prompt the compiler to change the order of operations. It now evaluates the expression in order from left to right, from parentheses to outside parentheses. This technique allows each repetition to include 15 connection operations, which are for smaller strings that do not grow, and only one for the ever-growing large sHTML. Figure 1 shows the comparison between this optimization method and the standard connection method in memory usage patterns.
　　

　

　　

Figure 1: Comparison of standard and parenthesis connections in memory usage patterns

　　
In certain cases, the use of parentheses can have a significant impact on performance and scalability, which will be further explained later in this article.
　　
StringBuilder
　　
We've found a quick way to solve string concatenation problems, and in most cases this approach achieves the best balance between performance and investment. However, if you want to further improve the performance of building large strings, the second approach is to reduce the number of string allocation operations. To do this, you need to use StringBuilder. StringBuilder is a class that maintains configurable string buffers, manages new pieces of text that are inserted into this buffer, and assigns strings only when the length of the text exceeds the length of the string buffer. The Microsoft. NET framework provides such a class (System.Text.StringBuilder) free of charge and recommends that it be used in all string concatenation operations that are performed in that environment. In ASP and traditional Visual Basic environments, we cannot access this class, so we need to create it ourselves. The following is an example of the StringBuilder class created using Visual Basic 6.0 (for simplicity, error handling code is omitted).
　　
Option Explicit
　　
' Default buffer initial size and growth factor
Private Const def_initialsize as Long = 1000
Private Const def_growth as Long = 1000
　　
' Buffer size and growth
Private M_ninitialsize as Long
Private M_ngrowth as Long
　　
' Buffer and buffer counter
Private M_stext as String
Private M_nsize as Long
Private M_npos as Long
　　
Private Sub Class_Initialize ()
' Set size and growth defaults
M_ninitialsize = Def_initialsize
M_ngrowth = Def_growth
' Initialize buffer
Initbuffer
End Sub
　　
' Set initial size and number of growth
Public Sub Init (ByVal initialsize as Long, ByVal growth as Long)
If initialsize > 0 Then m_ninitialsize = initialsize
If growth > 0 Then m_ngrowth = growth
End Sub
　　
' Initialize buffer
Private Sub Initbuffer ()
M_nsize =-1
M_npos = 1
End Sub
　　
' Increase buffer
Private Sub Grow (Optional minimimgrowth as Long)
' Initialize buffer (if necessary)
If m_nsize =-1 Then
M_nsize = M_ninitialsize
M_stext = space$ (m_ninitialsize)
Else
' Just Grow
Dim Ngrowth as Long
Ngrowth = IIf (M_ngrowth > Minimimgrowth,
M_ngrowth, Minimimgrowth)
M_nsize = m_nsize + ngrowth
M_stext = M_stext & space$ (ngrowth)
End If
End Sub
　　
' Resize the buffer to the currently used size