C # Discovery Tour-high performance asp.net tree list control (top)

An existing tree list control analysis discovers problems

Recently discovered that a tree-like list component called Dtree has been slow to load in asp.net project development. This is also the author's motives for writing this chapter. Chairman Mao taught us to find problems, analyze problems and solve problems. First we found the problem of slow loading of existing tree-like list Web controls, and then it was natural to analyze the problem.

The following figure is an example of the Dtree run interface

Analyze problems

Now we analyze the problem and analyze the program code that uses Dtree to generate a tree-like list, and you can see how the program works as shown in the following illustration

In such a program, the server-side C # code queries the database, and then a JavaScript code string is pieced together based on the data from the query, and then sent to the client, where the client browser obtains the JavaScript code string and starts executing it. In a JavaScript script it is also a string that fragments an HTML code string and then populates the HTML page with the generated HTML string using the Document.Write method or the Obj.innerhtml property provided by the browser.

This is the analysis of the dtree process, but the use of some other tree-like list controls is generally the case.

Now we are using this flowchart to determine which link is slow. Basically, the query speed of the database itself is no problem; passing query results to C # programs is not a problem, because the general database server and ASP.net programs are on one computer or on the same high-speed LAN; the process of C # programs generating JavaScript strings is also not a problem because C # The speed is quite fast, and there are StringBuilder to speed up the string patchwork operation, so as long as the logical algorithm is not a problem, speed is guaranteed. Overall, there is no speed problem within the server side.

Sending JavaScript strings from the server to the client over the network takes the length of the string divided by the speed of the network, and if the Web system is running on a high-speed LAN, the speed is not much, but if the Web program is running on a slow WAN or Internet, The length of the JavaScript string can affect the speed at which the program runs. Because the company system mainly runs in the LAN, therefore the network transmission speed is not the main problem.

In the client browser, the browser accepts and executes JavaScript scripting code, using string patchwork in JavaScript scripts to generate an HTML string to display the tree list. JavaScript code is interpreted in a very slow manner, and string piecing is a slow operation, and there is nothing in JavaScript to optimize string piecing. So the process of generating HTML strings from JavaScript code is slow, which is a speed bottleneck.

The JavaScript code also invokes the Document.Write function or innerHTML property provided by the browser to populate the resulting HTML string into the page, and the browser parses the HTML code and displays a tree-like list. Because the document.write or innerHTML is running inside the browser, the external program is out of control, and the speed is not slow, so there is no good optimization.

Through the above analysis, you can see that the entire display of the tree list in the process of the slowest link is to use JavaScript script to generate HTML code strings, followed by the data from the server to the client process. If a tree list is to display thousands of nodes, the JavaScript script will piece together hundreds of K or even MB of HTML strings, which is quite slow and can easily cause IE to prompt the user to continue executing the script because the script is running too slowly.

So JavaScript script generation of HTML strings will be our main optimization step, and it is also the focus of the newly developed tree-like list control.