使用包装函数

　　当我们试图使用Response.Write 语句这种方法时，最令人灰心的发现可能就是Response.Write 函数不能在每行的结尾处放置一个CRLF 。因此，当你从浏览器中阅读源代码时，本来布置得非常好的HTML，现在成了没有结束的一行。我想，你的下一个发现可能会更令你恐怖：在Response 对象中没有其姊妹函数Writeln 。所以，一个很明显的反应就是为Response.Write 函数创建一个包装函数，以便给每一行都附加一个CRLF 。

　…
　　writeCR("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞")
　　…
　　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("＜ html ＞" & _
　　"＜ head ＞" & _
　　"＜ title ＞Response Test＜ /title ＞" & _
　　"＜ /head ＞" & _
　　"＜ body ＞" & _
　　"＜ h1 ＞Response Test＜ /h1 ＞" & _
　　"＜ table ＞" & _
　　"＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞" & _
　　…
　　"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
　　"＜ /table ＞" & _
　　"＜ /body ＞" & _
　　"＜ /html ＞")

/app1/response3.asp的片段

　　以前的最佳（反应速度）= 8.08 msec/page

　　反应时间 = 7.05 msec/page

　　差 = -1.03 msec (减少12.7%)

　　目前，这是最优化的配置。

　　将连续的Response.Write 连接到一个单独语句中，在每行结尾处增加一个CRLF

　　考虑到那些要求他们的源代码从浏览器中看要很纯粹的人，我用vbCRLF 常量在前面测试中每行的结尾处插入了一些回车，然后重新运行。　　

　…
　　Response.Write("＜ html ＞" & vbCRLF & _
　　"＜ head ＞" & vbCRLF & _
　　" ＜ title ＞Response Test＜ /title ＞" & vbCRLF & _
　　"＜ /head ＞" & 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。