ASP Skill Collection (Official Authority edition)-5

Skills

Tip 13: Avoid redefining arrays Try to avoid Redim arrays. From a performance-sensitive standpoint, if your computer is limited by physical memory, it's best to start by setting the dimensions of the array to the worst-case scenario-rather than setting the dimension to the best scenario, and then redefining the dimensions as needed. This does not mean knowing that you don't need that much and that you should allocate too much memory. The following code shows that you do not need to use dim and Redim to solve the problem. <% Dim MyArray () Redim MyArray (2) MyArray (0) = "Hello" MyArray (1) = "Good-bye" MyArray (2) = "Farewell" ... ' Some other code, where you don't need more space, and then ... Redim Preserve myarray (5) MyArray (3) = "More Stuff" MyArray (4) = "Even more stuff" MyArray (5) = "yet more Stuff" %> A better approach would be to start the Dim array in the correct size (5 in this case), not the Redim array, and then enlarge the array. This may waste a bit of memory (if not all the elements are exhausted), but the speed is obtained. 　　 　　 Tip 14: Use response buffering You can buffer the entire page that is worth outputting by opening the response buffer. This minimizes the amount of data written to the browser, thereby improving overall performance. Each write has a large amount of overhead (including IIS and the amount of data sent over the cable), so the less you write, the better. The efficiency of TCP/IP is significantly higher in sending small chunks of data than sending large chunks of data, because of its slow start and nagling algorithms (for minimizing network congestion). There are two ways to turn on response buffering. First, you can use Internet Services Manager to turn on response buffering for your entire application. This is the recommended method, in IIS 4.0 and IIS 5.0, to open response buffering for new ASP applications by default. The second is to enable response buffering by placing the following lines of code at the beginning of the ASP page, on a per-page basis: <% Response.Buffer = True%> The line code must be executed before any response data is written to the browser (that is, before any HTML appears in the ASP script and before any Cookies are used by the Response.Cookies set). Generally, it is best to turn on response buffering for the entire application. This allows you to omit lines of code from each page above. Response.Flush The common problem with response buffering is that the user feels that the ASP page is unresponsive (although overall response time improves) because they need to wait until the entire page is built to see the page. For long-running pages, you can turn off response buffering by setting Response.Buffer = False. However, a better strategy is to use the Response.Flush method. This method refreshes all HTML that is painted by the ASP into the browser. For example, after drawing 100 rows of a table with 1,000 rows, the ASP can invoke Response.Flush to force the result to be drawn to the browser, which allows the user to see the first 100 rows before the remaining rows are ready. This technology gives you two of the best things in the list-the combination of response buffering and the gradual display of data in the browser. (Note that in the example of the above 1,000-row table, many browsers do not start drawing the table until they see the </table> closing tag.) Please check the support of the target browser. To work around this problem, split the table into multiple tables with fewer rows, and then call Response.Flush after each table. The new version of Internet Explorer will draw the table before the table is completely downloaded, especially if the column widths of the specified table are drawn faster; This avoids forcing Internet Explorer to calculate the column width by measuring the contents of each cell. ） Another common problem with response buffering is the large amount of memory used by the server when generating large pages. For this problem, in addition to the skills required to generate a large page, it can be solved by using response.flush skillfully. 　　 　　 tip 15: Batch inline scripts and Response.Write statements VBScript syntax <% = Expression%> writes the value of an expression to an ASP output stream. If the response buffer is not open, each sentence of these statements causes the data to be written to the browser over the network, in the form of many small packages. It's very slow. In addition, interpreting a small number of scripts and HTML will result in a switch between scripting engines and HTML, and also reduced performance. Therefore, use the following tip: Replace the inline dense combination expression with a call to Response.Write. For example, in the following example, there is a write to the response stream for each field in each row, and there are many switches between VBScript and HTML in each row: <table> <% for each fld in Rs. Fields%> <th><% = fld. Name%></th> <% Next While not Rs. Eof %> <tr> <% for each fld in Rs. Fields%> <td><% = fld. Value%></td> <% Next </tr> <% Rs. MoveNext Wend%> </table> Here is a more efficient code that has a write to the response stream in each row. All code is contained within a single VBScript block: <table> <% For each fld in Rs. Fields Response.Write ("<th>" & fld. Name & "</th>" & VbCrLf) Next While not Rs. Eof Response.Write ("<tr>") For each fld in Rs. Fields%> Response.Write ("<td>" & fld. Value & "</td>" & VbCrLf) Next Response.Write "</tr>" Wend %> </table> This technique is more useful when response buffering is disabled. It is a good idea to enable response buffering and then observe whether batch Response.Write is helpful for performance. (In this particular case, a nested loop of the body of the table is built (while not Rs.) EOF ...) Can be replaced by a carefully constructed, GetString invocation. ）