本篇教程主要介绍：将ASP生成的内容写入响应流中最有效的方法，即用 Response.Write 和 <%=%> 向客户端输出内容时的效率测试。
使用ASP的一个最主要原因是在服务器上生成动态内容。所以很明显，我们测试的起点是确定将动态内容发送到响应流中的最适合的方式。
在多种选择中，有两个是最基本的：一是使用内联ASP标记，另一个是使用Response.Write 语句。
为测试这些选择，我们创建了一个简单的ASP页面，其中定义了一些变量，然后将它们的值插入表格中。虽然这个页面很简单也不是很实用
，但它允许我们分离并测试一些单独的问题。
使用ASP内联标记
第一个测试包括使用内联ASP标记<%=x%>，其中x是一个已赋值的变量。到目前为止，这个方法是最容易执行的，并且它使页面的HTML部分
保持一种易于阅读和维护的格式。
<%
OPTION EXPLICIT '此句作用是强制使用每个变量前必须先定义
Dim FirstName
Dim LastName
Dim MiddleInitial
Dim Address
Dim City
Dim State
Dim PhoneNumber
Dim FaxNumber
Dim EMail
Dim BirthDate
FirstName = "John"
MiddleInitial = "Q"
LastName = "Public"
Address = "100 Main Street"
City = "New York"
State = "NY"
PhoneNumber = "1-212-555-1234"
FaxNumber = "1-212-555-1234"
EMail = "john@public.com"
BirthDate = "1/1/1950"
%>
Response Test
Response Test
| First Name: | <%=FirstName%> |
| Middle Initial: | <%=MiddleInitial%> |
| Last Name: | <%=LastName%> |
| Address: | <%=Address%> |
| City: | <%=City%> |
| State: | <%=State%> |
| Phone Number: | <%=PhoneNumber%> |
| Fax Number: | <%=FaxNumber%> |
| EMail: | <%=EMail%> |
| Birth Date: | <%=BirthDate%> |
/app1/response1.asp的完整代码
以前的最佳（反应速度） = 8.28 msec/page
在HTML的每一行使用Response.Write 语句
许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是，在输出页面和处理页面施加反应时间的过程中，如果web 服务器不
得不在发送纯HTML和处理脚本之间进行转换，就会发生一种被称为上下文转换的问题。大部分程序员一听到这里，他们的第一反应就是将原始
的HTML的每一行都包装在Response.Write函数中。
…
Response.Write("")
Response.Write("
")
Response.Write("
Response Test")
Response.Write("")
Response.Write("
")
Response.Write("
Response Test
")
Response.Write("
")
Response.Write("
| First Name: | " & FirstName & " |
")
Response.Write("
| Middle Initial: | " & MiddleInitial & "/td > |
")
…
/app1/response2.asp的片段
以前的最佳（反应速度） = 8.28 msec/page
反应时间 = 8.08 msec/page
差= -0.20 msec (减少 2.4%)
我们可以看到，使用这种方法与使用内联标记的方法相比在性能上获得的收益非常小，这也许是因为页面给服务器装载了一大堆小的函数
调用。这种方法最大的缺点是，由于现在HTML都嵌入脚本中，所以脚本代码变得更加冗长，更加难以阅读和维护。
使用包装函数
当我们试图使用Response.Write 语句这种方法时，最令人灰心的发现可能就是Response.Write 函数不能在每行的结尾处放置一个CRLF 。
因此，当你从浏览器中阅读源代码时，本来布置得非常好的HTML，现在成了没有结束的一行。我想，你的下一个发现可能会更令你恐怖：在
Response 对象中没有其姊妹函数Writeln 。所以，一个很明显的反应就是为Response.Write 函数创建一个包装函数，以便给每一行都附加一
个CRLF 。
…
writeCR("
| First Name: | " & FirstName & " |
")
…
SUB writeCR(str)
Response.Write(str & vbCRLF)
END SUB
/app1/response4.asp的片段
以前的最佳（反应速度）= 8.08 msec/page
反应时间= 10.11 msec/page
差 = +2.03 msec (增加 25.1%)
当然，由于这种方法有效地使函数调用次数加倍，其对性能的影响也很明显，因此要不惜一切代价避免。具有讽刺意味的是CRLF也向反应
流中为每行增加了2个字节，而这是浏览器不需要呈现到页面上的。格式化良好的HTML所做的一切就是让你的竞争者更容易阅读你的HTML源代码
并理解你的设计。
将连续的Response.Write 连接到一个单独语句中
不考虑我们前面用包装函数进行的测试，下一个合乎逻辑的步骤就是从单独的Response.Write 语句中提取出所有的字符串，将它们连接到
一个单独语句中，这样就减少了函数调用的次数，极大地提高了页面的性能。
…
Response.Write("" &_
"
" &_
"
Response Test< /title >" &_</p>
<p> "</head>" &_</p>
<p> "<body>" &_</p>
<p> "<h1>Response Test</h1>" &_</p>
<p> "<table>" &_</p>
<p> "<tr><td><b>First Name:</b></td><td>" & FirstName & "</td></tr>" &_</p>
<p>…</p>
<p> "<tr><td><b>Birth Date:</b></td><td>" & BirthDate & "</td></tr>" &_</p>
<p> "</table>" &_</p>
<p> "</body>" &_</p>
<p> "</html>")</p>
<p> /app1/response3.asp的片段</p>
<p> 以前的最佳（反应速度）= 8.08 msec/page</p>
<p> 反应时间 = 7.05 msec/page</p>
<p> 差 = -1.03 msec (减少12.7%)</p>
<p> 目前，这是最优化的配置。</p>
<p> 将连续的Response.Write 连接到一个单独语句中，在每行结尾处增加一个CRLF</p>
<p> 考虑到那些要求他们的源代码从浏览器中看要很纯粹的人，我用vbCRLF 常量在前面测试中每行的结尾处插入了一些回车，然后重新运行。</p>
<p> </p>
<p> …</p>
<p> Response.Write("<html>" & vbCRLF &_</p>
<p> "<head>" & vbCRLF &_</p>
<p> " <title>Response Test" & vbCRLF &_
"" & vbCRLF &_
…
/app1/response5.asp的片段
前面的最佳（反应速度）= 7.05 msec/page
反应时间= 7.63 msec/page
差 = +0.58 msec (增加 8.5%)
运行的结果在性能上有一点降低，这也许是由于额外的串联和增加的字符量。
回顾和观测
从前面有关ASP输出的测试中可以得出一些规则：
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数来附加CRLF。
* 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
