/app1/response1.asp的完整代码
以前的最佳(反应速度) = 8.28 msec/page
在HTML的每一行使用Response.Write 语句
许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是,在输出页面和处理页面施加反应时间的过程中,如果web 服务器不得不在发送纯HTML和处理脚本之间进行转换,就会发生一种被称为上下文转换的问题。大部分程序员一听到这里,他们的第一反应就是将原始的HTML的每一行都包装在Response.Write函数中。
…
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 >Middle Initial:< /b >< /td >< td >" & MiddleInitial & "< /td >< /tr >")
… <
/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("< tr >< td >< b >First Name:< /b >< /td >< td >" & FirstName & "< /td >< /tr >")
…
SUB writeCR(str)
Response.Write(str & vbCRLF)
END SUB
/app1/re