结论

　　本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题，我设置了最后一个测试，在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多Response.Write 声明、关闭了缓冲器、设置了默认语言、去掉了Option Explicit 引用并初始化了错误句柄。

　　< %@ LANGUAGE=VBSCRIPT % >
　　 < %
　　 On Error Resume Next
　　 FirstName = "John"
　　 …
　　 BirthDate = "1/1/1950"
　　 Response.Write("< html >")
　　 Response.Write("< head >")
　　 Response.Write(" < title >Response Test< /title >")
　　 Response.Write("< /head >")
　　 Response.Write("< body >")
　　 Response.Write("< h1 >Response Test< /h1 >")
　　 Response.Write("< table >")
　　 Response.Write("< tr >< td >< b >First Name:< /b >< /td >< td >" &_
"FirstName & "< /td >< /tr >")
　　 …
　　 Response.Write("< tr >< td >< b >Birth Date:< /b >< /td >< td >" &_
" BirthDate & "< /td >< /tr >")
　　 Response.Write("< /table >")
　　 Response.Write("< /body >")
　　 Response.Write("< /html >")
　　 % >

　　/app2/final_1.asp片段

　　基准值 = 5.57 msec/page
　　 反应时间 = 8.85 msec/page
　　 差 = +3.28 msec (58.9% 增加)

　　听起来可能很明显，但是理解更重要，那就是我们放置在页面上的代码会对性能有影响。页面上的小变化有时会大大地增加反应时间。

规则概括

　　* 避免内联ASP的过多使用。
　　 * 总是将连续Response.Write 语句连接进一个单独语句内。
　　 * 永远不要在Response.Write 周围使用包装函数以附加CRLF。
　　 * 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
　　 * 总是通过服务器设置开启缓冲器。
　　 * 只要使用适度，ASP注释对性能的影响很小或根本没有影响。
　　 * 设置服务器的默认语言配置以与站点上使用的语言相匹配。
　　 * 除非你使用非默认语言，不要设置语言声明。
　　 * 在VBScript中总是使用Option explicit 。
　　 * 在不需要的情况下，总是在页面或应用程序的水平上关闭Session状态。
　　 * 只有当代码在页面之间共享时才使用Include 文件。
　　 * 在一个页面上，如果代码要使用一次以上，就将代码封入函数区。
　　 * 适当时候，将变量声明移到函数范围内。
　　 * 只有会发生超出测试或控制能力之外的情况时才使用错误句柄。
　　 * 只有当两个或更多操作被作为一个单元执行时，才使用上下文处理。

　　现在回顾一下，有许多问题可以作为普遍性的方针：

　　* 避免冗余--不要设置那些默认状态下已经设置的属性。
　　 * 限制函数调用的次数。
　　 * 缩小代码的范围。

　　在本文的第二部分，我们将探索有关ADO和COM对象一些深入的问题。

　　>>>>>未完待续<<<<<