技巧
技巧1：给应用层文件使用GLOBAL.ASA
技巧2：从产品源代码中移去HTML注释
技巧3：多个Response.write声明
技巧4：使用＜OBJECT＞标志例示对象
技巧5：尽可能的使用本地（局部）变量
技巧6：避免多维数组
技巧7：避免公用（全局）变量
技巧8：使用文字路径
技巧9：使用"Dictionary"对象
技巧10：充分利用浏览器的回退功能
技巧11：避免使用服务器端变量
技巧12：使用"option explicit"
技巧13：将采集到的值拷贝到本地（局部）变量当中
技巧14：谨慎使用session对象
技巧15：做性能测试
*技巧1：给应用层文件使用GLOBAL.ASA
将文件载入GLOBAL.ASA中的一个应用层数组中，而不是通过使用ASP文件系统对象在页面上读取文件。
GLOBAL.ASA可用于指定事件脚本，也可用于声明拥有session或应用程序范围的对象。它不直接显示给用户，而是存储应用层事件的信息和对象。然后通过页面就可以指向存有数据的应用层数组。这就意味着每有一个服务器端请求就读一次文件，不是每个用户每页读一次。你可以运行一个独立的ASP文件去刷新应用层数组的内容，同时你也可以考虑使用dictionary对象（见技巧9）。
这个技巧可以大大加快你的系统速度。
那么将如何实现该技巧呢？
如果你是一个脚本编写人员，必须使用文件系统对象读取文件放入一个数组或一个dictionary对象中。然后在GLOBAL.ASA中读取文件并且把数组（放有你读取的文件内容）或dictionary对象放到应用层声明中。这样就可让用户在数组或dictionary对象中存取信息，而不必每次通过一个ASP请求去提交信息。
但也许你会想"如果缓存中的内容需要更新又该怎么办呢？我敢打赌不会用到。"其实不然。如果缓存中的内容需要更新，你可以调用一个包含有可执行应用程序锁定命令脚本的仅管理员可存取的ASP文件，在数组或dictionary对象中更新缓存信息，最后执行应用程序锁定命令。
*技巧2：从产品源代码中移去HTML注释（IIS3.0适用）
不错，难写的肯定也难懂。开个玩笑，这不代表要你把所有的HTML注释去掉（脚本注释就挺好的），大范围的HTML文本都能成批的拷贝到客户端。这样的话，你的脚本在IIS3.0上会运行得更快（在IIS4.0中，HTML注释不再会导致执行速度的降低）。
*技巧3：多个Response.write声明
如果你是在代码中的好几个地方用格式书写输出结果，那么考虑一下把这些结果合到一块，用一个Response.write语句写出来。然后你再看看你的HTML代码和vbscript脚本的组成。不要把HTML和vbscript脚本散布得太开，尽量写成成块的HTML和vbscript脚本。
*技巧4：使用＜OBJECT＞标志例示对象
如果你需要指向那些也许用不着的对象，那么就用＜OBJECT＞标志例示，而不是用Server.createobject.用Server.createobject将立刻生成该对象，如果你以后都用不着它的话，就等于浪费资源。
*技巧5：尽可能的使用本地（局部）变量
（以下的新技巧将取代较早前发布的"在一行内定义变量"，其中包含有一些错误观点）：
局部变量是在子程序和函数中定义的（也就是常说局部范围的变量），这些变量被编译成数字指向并放入一张表中。这些局部变量的指向可以通过一次编译完成。而全局变量则是在运行时被执行的。这就意味着局部变量的存取要比全局变量快好几倍。而且，多维全局变量是其中最慢的，当第一次使用一个多维全局变量时，在新的对象产生之前，就要在整个对象模型中搜索一遍同名的对象。
以下是一个非常常见的例子：
Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc then
运行时产生如下结果：
1）变量Foo被定义为一个全局变量2）变量bar被定义为Foo的一个成员3）变量blah被定义为Foo.bar的一个成员4）变量qaz被定义为Foo.bar.blah的一个成员5）调用Foo.bar.blah.quaz(1)6）重复1至3。系统并不知道如果调用qaz改变了对象模型1-3步必须重新执行7）定义baz为Foo.bar.blah的成员，输出值8）重复1-3，执行zaq9）重复1-3，执行abc
正如你看到的，效率极其低下，最快的方法就是把这些代码写在vbscript中：
Set myobj = Foo.bar.blah ' do the resolution of blah ONCEMyobj.baz = myobj.qaz(1)If Myobj.zaq = Myobj.abc then
*技巧6：避免重复定义数组
当我们在使用dim时，避免重新定义数组。因为你可能要用redim去重新定义数组的大小。至于要做这样的操作的话，如果你的机器内存不是很大，那么最好在一开始就考虑到最坏的打算去设置数组的长度或者设置最佳状态时的长度，在非常必要时才使用redim。当然这样并不意味着要去增加内存，如果你不是很需要的话。
以下举例说明不恰当的使用redim
其实在开始就定义myarray（5），而以后需要的话再用redim去增加他的大小，这样的话可能会占用一些内存，但速度就要快得多了。
*技巧7：避免公用（全局）变量
不要使用用public定义的变量。如果你是写vbscript或在ActiveX控件或java applet中存取变量，那么尽可能避免公用变量。public关键字通常是为以后使用设计的，既然public不能给你带来什么好处，那最好还是用dim吧。
*技巧8：使用绝对路径
如果可能的话尽量避免使用相对路径，而使用绝对路径。使用相对路径将需要IIS返回当前服务器路径，这就意味着对IIS的特殊请求造成执行速度低下。
注：慢点就慢点呗，使用相对路径移植什么的都方便得多呀。
*技巧9：使用"Dictionary"对象
VBScript中提供的dictionary对象可提供快速查找和任意带关键字数据的存储。通过dictionary对象可以根据关键字存取数组中的各项数据，这样就能更快地找到在内存中不连续的内容（因为你是指定你正在使用的关键字，而不是要知道对象在数组中存放的位置）。如果你要查找的是非线性的关键字数据，使用dictionary对象就要快得多了。
然而，如果关键字数据在内存中是连续的，那么数组在查找、存储数据起来将更快。同时也需要注意的是在dictionary中建立索引要比在数组中慢。你应该选择对你来说效果最好的数据结构。
*技巧10：充分利用浏览器的回退功能
如果你使用的是个smart的浏览器，那么他会帮你做很多的回退工作，只要用得着，不妨多用用。那么，通过你的脚本执行回退，当有任何错误发生时你可以回到前面去，并从后访问数据库。但要记住的是，当你访问服务器上存在的数据库时就要执行一次对数据库的操作。如果你要返回的那个表单有很多变量的话，那就有点划不来了。如果你确实知道你需要在客户端执行很多代码，那么为了加快执行速度把代码移到客户端。当你在客户端运行时，处理器就归你了，服务器呢，只好用他自身的处理能力去处理他所接到的请求。
还有个好办法，如果你使用的表单中用了很多服务器端的脚本并且有不少条件输入，那么最好把这些触发反应的代码放到客户端脚本引擎中去（比如vbscript，javascript）。忽略这些，服务器代码运行得就快了，因为对于那些不是很必要的代码就不送到服务器端执行了。当然这仅对那些比较小的代码适用，至于大的嘛，就不太合适了。
*技巧11：避免使用服务器端变量
通过服务器端变量进行访问数据时，就需要web向服务器提出请求，然后收集所有的服务器端变量，而不仅仅只是你请求的那个变量。这就类似于你要从发霉阁楼的盒子里找一样特定的东西。当你要找那个东西时，首先要从阁楼里找到盒子。当你请求一个变量时服务器也是一样，当遇到你请求的哪个变量时触发执行，然后再去请求那些不会引起执行点的变量。
*技巧12：使用"option explicit"
在asp文件中写上。和c不同，vb允许你在不强制定义变量之前就可以使用该变量。把option explicit打开有助于识别没定义的变量，使用没定义的变量就会出现错误提示信息。同时也可以使那些没申明的局部变量非法。没申明的局部变量和全局变量一样慢（比定义过的局部变量要慢一倍）。把option explicit打开自然能帮你把这些小虫子从你的代码中去掉。
*技巧13：将采集到的值拷贝到本地（局部）变量当中
如果有一些值是你要反复用到的话，把这些值用局部变量的形式拷贝到客户端。每次当你要用到这些值时，就省去了你去那一堆值里面去找了，这样也就加快了脚本运行速度。
*技巧14：谨慎使用session对象
使用session对象可以存储一些用户特殊信息。当用户在该应用程序的不同页之间跳转，存放在session中的变量不会丢失，相反，这些变量在整个用户过程中一直保留。当一个页面被一个未有session的用户请求时，web服务器会自动建立一个session对象。当session的时间限制到了或是被中断了时，服务器就会撤消session对象。为了避免这种情况，你可以把session属性关闭。然而在iis3.0中在每个应用中的session属性不能关闭。把整个服务器中的session关闭速度会快一些，但这样会损失很多功能。最好是需要时谨慎使用session对象
当你在整个应用中都用到session对象时，注意要快点用，否则session对象将会被重置。在iis4.0中，每个应用基础中的session状态都可以被激活，也可以在specified.asp文件中被取消。
*技巧15：做性能测试
这就没什么好翻的，一把好刀就是要多磨一磨，好程序也是一样，多用用，就知道毛病在哪了。
调谐不是技术，是艺术！
优化你的程序不是一件小事，需要你从一点一滴做起，从每一个细节做起，并且养成良好的编程习惯。我是学语言的，喜欢有严正的风格。
