15 ASP Usage Tips (Chinese version)

Skills | Chinese Author: Nancy cluts, Microsoft technology development Engineer

Tip 1: Use Global.asa for application-tier files
Tip 2: Remove the HTML annotation from the product source code
Tip 3: Multiple Response.Write declarations
Tip 4: Use <OBJECT> flag to sample objects
Tip 5: Use local (local) variables as much as possible
Tip 6: Avoid multidimensional arrays
Tip 7: Avoid public (global) variables
Tip 8: Use a text path
Tip 9: Use the "Dictionary" object
Tip 10: Take full advantage of the browser's fallback function
Tip 11: Avoid using server-side variables
Tip 12: Use "Option Explicit"
Tip 13: Copy the collected values to a local (local) variable
Tip 14: Use the Session object with caution
Tip 15: Do a performance test

* Tip 1: Use Global.asa for application-tier files

Loads a file into an application-tier array in Global.asa instead of reading the file on the page by using an ASP file system object.
GLOBAL. ASA can be used to specify event scripts or to declare objects that have session or application scope. Instead of displaying directly to the user, it stores information and objects for application-level events. You can then point to an array of application layers that have data through the page. This means that every server-side request to enroll in a file is not read every page per user. You can run a stand-alone ASP file to refresh the contents of the application-tier array, and you can also consider using the Dictionary object (see Tip 9).
This technique can greatly speed up your system.
So how will this trick be implemented?
If you are a scripting person, you must use a file system object to read the file into an array or a Dictionary object. It then reads the file in the Global.asa and places the array (with the contents of the file you read) or the Dictionary object in the application-level declaration. This allows the user to access information in an array or Dictionary object without having to submit the information each time through an ASP request.
But you might think, "What if the content in the cache needs to be updated?" I bet it's not going to work. Fact If the contents of the cache need to be updated, you can call an administrator-only accessible ASP file containing an executable application lock command script, update the cached information in an array or Dictionary object, and finally execute the application Lockdown command.

* Tip 2: Remove the HTML annotation from the product source code (IIS3.0 applicable)
Yes, difficult to write must also be difficult to understand. A joke, this does not mean you have to remove all the HTML comments (the script annotation is good), a large range of HTML text can be copied to the client in batches. In this way, your script will run faster on IIS3.0 (in IIS4.0, HTML annotations will no longer cause slower execution).

* Tip 3: Multiple Response.Write statements
If you are writing the output in <%=...%> format in several places in your code, consider putting the results together and writing with a Response.Write statement. Then you'll look at your HTML code and the composition of the VBScript script. Instead of spreading HTML and VBScript scripts too far, try to write chunks of HTML and VBScript scripts.

* Tip 4: Use <OBJECT> flag to sample objects
If you need to point to objects that may not be needed, use the <OBJECT> flag example, Instead of using Server.CreateObject. The object is immediately generated with Server.CreateObject, and if you don't use it later, it's a waste of resources.

* Tip 5: Use local (local) variables as much as possible
(The following new techniques will replace the earlier issue of "defining variables within a row", which contains some erroneous ideas):
Local variables are defined in subroutines and functions (that is, variables that often say local scope) that are compiled into numbers to point to and put into a table. The points of these local variables can be completed by one compilation. The global variable is executed at run time. This means that local variables can be accessed several times faster than global variables. Also, multidimensional global variables are the slowest, and when a multidimensional global variable is used for the first time, the entire object model is searched for an object with the same name, before the new object is produced.
Here's a very common example:
Foo.bar.blah.baz = Foo.bar.blah.qaz (1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then
The runtime produces the following results:
1 variable foo is defined as a global variable
2 the variable bar is defined as a member of Foo
3) variable blah is defined as a member of the Foo.bar
4) variable Qaz is defined as a member of the Foo.bar.blah
5) Call Foo.bar.blah.quaz (1)
6) Repeat 1 to 3. The system does not know if the call Qaz changed the object model 1-3 steps must be performed again
7) define Baz as Foo.bar.blah member, output value
8) Repeat 1-3, execute Zaq
9) Repeat 1-3, perform ABC
As you can see, the quickest way to do this is to write the code in VBScript:
Set myobj = Foo.bar.blah ' Do the resolution of blah ONCE
Myobj.baz = Myobj.qaz (1)
If Myobj.zaq = Myobj.abc Then

* Tip 6: Avoid repeating the definition of an array
When we use dim, avoid redefining the array. Because you might want to use ReDim to redefine the size of the array. As for such an operation, if your machine memory is not very large, it is best to consider the worst in the beginning to set the length of the array or set the length of the best state, when it is necessary to use ReDim. Of course this doesn't mean adding memory, if you don't need it very much.
The following examples illustrate improper use of ReDim
<%
Dim myarray ()
Redim Myarrray (2)
MyArray (0) = "Hello"
MyArray (1) = "Good-bye"
.
.
.
Some other code where and the up needing
More space happens then ...
Redim Preserve myarray (5)
MyArray (2) = "More Stuff"
MyArray (3) = "Even more stuff"
MyArray (4) = "Yet more Stuff"
%>
In fact, at the beginning of the definition of MyArray (5), and later need to use ReDim to increase his size, such words may occupy some memory, but the speed will be much faster.

* Tip 7: Avoid public (global) variables
Do not use variables that are defined with public. If you are writing VBScript or accessing variables in ActiveX controls or Java applets, avoid common variables as much as possible. The Public keyword is usually designed for later use, and since public does not benefit you, it is best to use dim.



* Tip 8: Use absolute path
If possible, avoid using relative paths, and use absolute paths. Using a relative path will require IIS to return to the current server path, which means that the special requests for IIS cause low execution speed.
Note: Slow down, it's much more convenient to use a relative path to transplant anything.

* Tip 9: Use the "Dictionary" object

The Dictionary object provided in VBScript provides fast lookup and storage with any keyword data. The Dictionary object allows you to access the data in the array based on the keyword so that you can find the content that is not contiguous in memory faster (because you are specifying the keyword you are using rather than knowing where the object is stored in the array). If you're looking for non-linear keyword data, it's much quicker to use the Dictionary object.
However, if the keyword data is contiguous in memory, the array will be faster to find and store the data. It is also necessary to note that indexing in dictionary is slower than in arrays. You should choose the data structure that works best for you.


* Tip 10: Take full advantage of the browser's fallback function
If you are using a smart browser, then he will help you do a lot of rollback work, as long as it is useful to use more. Then, perform a fallback through your script, and you can go back to the front when anything goes wrong and access the database from behind. But keep in mind that when you access a database that exists on the server, you perform a database operation once. If the form you want to return has a lot of variables, it's a bit out of the way. If you do know that you need to execute a lot of code on the client, move the code to the client to speed up execution. When you run on the client, the processor is yours, and the server has to use his own processing power to handle the requests he has received.
There's also a good idea that if you use a form that uses a lot of server-side scripting and has a lot of input, it's best to put the trigger code in the client script engine (such as Vbscript,javascript). Ignoring these, the server code runs fast, because the code that is not very necessary is not sent to the server side for execution. Of course, this is only for those relatively small code to apply, as for the big, it is not appropriate.