ASP Classic Performance Question

[Merovingian]

I'm maintaining an ASP Classic file that has HTML withing
Response.Write methods...such as.


<%
Response.Write "<table><tr><td>"
Response.Write testVariable
Response.Write "</td></tr></table>"
%>

Would their be a performance hit if I were to write this instead?

<table><tr><td><%=testVariable%></td></tr></table>

I think, no, but I need some confirmation.

Thanks for any advice/suggestions.

 

[James Jones]

That is what i usually do. works fine for me.


James Jones

 

[Bob Barrows [MVP]]

I'm maintaining an ASP Classic file that has HTML withing
Response.Write methods...such as.


<%
Response.Write "<table><tr><td>"
Response.Write testVariable
Response.Write "</td></tr></table>"
%>

Would their be a performance hit if I were to write this instead?

<table><tr><td><%=testVariable%></td></tr></table>

I think, no, but I need some confirmation.

No. I think in IIS4, there used to be, but that is no longer a factor.

 

[Merovingian]

Thanks Bob!

No. I think in IIS4, there used to be, but that is no longer a factor.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

 

[Merovingian]

Could I get some links to back up the performance between the two
examples?

 

[Merovingian]

This is a topic of discussion between me and another developer and I
can't seem to convey that it makes no difference except that the
readability and mantainability of the code is easier without all the
markup in the ASP tag delimiters. Personally, we wouldn't be having
this conversation if we were using ASP.NET.

 

[Bob Barrows [MVP]]

I doubt a cite* would convince him. I suspect the only thing that would
probably convince him is a test. So take 5 minutes and create a test package
and run it.


*I have no cites. I really don't remember where I read that the performance
issue was solved with IIS 5.1. You may find someone with a link in the iis
group.

 

[McKirahan]

I'm maintaining an ASP Classic file that has HTML withing
Response.Write methods...such as.

<%
Response.Write "<table><tr><td>"
Response.Write testVariable
Response.Write "</td></tr></table>"
%>

Would their be a performance hit if I were to write this instead?

<table><tr><td><%=testVariable%></td></tr></table>

I think, no, but I need some confirmation.

Thanks for any advice/suggestions.

VBScript String Concatenation
(And Why It Should Be Avoided Like The Plague)
http://www.asp101.com/articles/marcus/concatenation/default.asp
"... here are the results of the benchmarks ..."


How do I make my ASP pages more efficient?
http://classicasp.aspfaq.com/general/how-do-i-make-my-asp-pages-more-efficie
nt.html
"Don't generate large strings in single variables -- concatenation is very
expensive."


Here's what I do:

<%
Dim arrSTR()
ReDim arrSTR(100)
Dim intSTR
intSTR = 0
Dim strSTR
'*
Append "<table border='0'>"
Append "<tr>"
Append " <th>`Hello World!`<hr></th>"
Append "</tr>"
Append "</table>"
'*
Response.Write Concat()

Sub Append(strSTR)
'****
'* Append strings to array entries ReDim as needed; (see "Concat()").
'****
strSTR = strSTR & ""
If intSTR > UBound(arrSTR) Then
ReDim Preserve arrSTR(UBound(arrSTR) + 100)
End If
arrSTR(intSTR) = strSTR & vbCrLf
intSTR = intSTR + 1
End Sub

Function Concat()
'****
'* Concatenates array entries into a single string; (see "Append()").
'****
Redim Preserve arrSTR(intSTR)
Concat = Replace(Join(arrSTR,""),"`",Chr(34))
Erase arrSTR
ReDim arrSTR(100)
intSTR = 0
End Function
%>

Only one Response.Write() and the code is lot more readable.

 

[Michael D. Kersey]

I'm maintaining an ASP Classic file that has HTML withing
Response.Write methods...such as.
<%
Response.Write "<table><tr><td>"
Response.Write testVariable
Response.Write "</td></tr></table>"
%>
Would their be a performance hit if I were to write this instead?
<table><tr><td><%=testVariable%></td></tr></table>

No.
An ASP page is, on the first request for that page, compiled to p-code,
executed and the p-code cached for subsequent executions. During the
compile step, any embedded HTML is replaced by a call to the
(unpublished) Response.WriteBlock(N) method. Here N refers to the Nth
"block" of embedded HTML. Blocks numbers start with 0. You can test this
by writing explicit calls to Response.WriteBlock() for your edification.

Consequently output is either from a Response.Write() call or a
Response.WriteBlock() call. Any difference in speed is insignificant.

We've discussed this before many times on these newsgroups:
http://groups.google.com/groups?as_...81&as_maxd=21&as_maxm=9&as_maxy=2006&safe=off

Further details on how ASP is compiled and executed
See in particular "Appendix 3: ASP Caching":
http://www.microsoft.com/technet/pr...ptimize/iis5tune.mspx#XSLTsection130121120120

Explanation of compilation with examples of ASP p-code:
http://groups.google.com/group/micr...sp.db/msg/41be6029942157e6?dmode=source&hl=en

 

[Merovingian]

http://www.microsoft.com/technet/pr...serv/technologies/iis/tips/asptips.mspx#EHJAC

Apparently it is more efficient to put your HTML into Response.Writes
while in a loop. It's still hard for me to accept it.

 

[Anthony Jones]

http://www.microsoft.com/technet/pr...serv/technologies/iis/tips/asptips.mspx#EHJAC

Apparently it is more efficient to put your HTML into Response.Writes
while in a loop. It's still hard for me to accept it.

Certainly with response.buffer off it will be slower but with response
buffering on I seriously doubt that using inline html would be slower than a
loop of response writes.

The premise of the linked item above is that multiple calls a Response.Write
(or Response.WriteBlock) is slower than a single call. However in order to
modify your code to make a single call you would need to perform string
concatenation in Script. As Michael has already pointed out this is
(relatively at the level we are discussing) pretty slow especially in
VBScript.

There is another factor to consider. String literals encoded in to ASP
Script code will get compiled into the p-code as Unicode strings (these
strings are typically twice as big as they were in the original file). When
response.write receives this unicode string it needs to perform a conversion
on the string to the code page current for the response. In line content
OTH will be sent as a block bytes as is in the file no conversion to or from
unicode will be performed.

Hence I suspect that if you could build a test senstive enough to discover
the differences whilst being sure that other factors are fully accounted for
(which I doubt can truely be done) then you'd find that inline HTML is
faster (with buffering on.)

There is also yet another factor to bear in mind if you need to generate
multilingual output by using UTF-8 encoded files. String literals in script
in a UTF-8 encoded file must be strictly with in the ASCII character set.

Anthony.

 

[Dave Anderson]

This is a topic of discussion between me and another developer
and I can't seem to convey that it makes no difference except
that the readability and mantainability of the code is easier
without all the markup in the ASP tag delimiters. Personally,
we wouldn't be having this conversation if we were using ASP.NET.

With the differences as small as they are (if they exist at all),
readability and maintainability ought to be enough, period. Once again, I
quote Eric Lippert:

"If you care about maximizing performance, using a late-bound
unoptimized bytecode-interpreted dynamically-typed language
is probably a bad choice"

There is little to suggest that context-switching has been an issue at all
since IIS4. I assert that the TechNet article was written for IIS4 and left
unchanged for the IIS5 documentation. I submit as evidence this phrase: "If
response buffering is not turned on". Had the article been written for IIS5,
it would be: "If response buffering is turned off".

 

[Michael D. Kersey]

http://www.microsoft.com/technet/pr...serv/technologies/iis/tips/asptips.mspx#EHJAC

The article is incorrect in this regard. I believe it is incorrect for
versions of IIS back to at least IIS3 (my first experience with IIS). I
don't know about earlier versions of IIS. I believe it conflates two
distinct topics:
a. Buffered of output in ASP and
b. use of Response.Write() vs. embedded HTML (Response.WriteBlock())
Finally I believe it assumes an incorrect execution model of ASP.

Concerning Tip 15 of the article specifically:
1. The first sentence addresses buffering I/O and is orthogonal to the
question of whether Response.Write or embedded HTML
(Response.WriteBlock()) is faster.

2. The third sentence

Also, interspersing small amounts of script and HTML causes switching between the script engine and HTML, reducing performance.

is nonsense.

Why? Because there is no "switching between the script engine and HTML".
In your example, all output to the client browser from ASP is generated
by either an explicit Response.Write() call or, in the case of embedded
HTML, a Response.WriteBlock() call.

There _is_ true context switching in the usual sense, wherein the
operating system interrupts execution of the ASP script engine p-code to
handle I/O. But that would occur regardless of whether one uses
Response.Write() or embedded HTML (Response.WriteBlock()) in their code.
And it would occur to the same degree for either.

So don't believe everything you read on Microsoft's site (thanks to
Anthony Jones). And you can always test and see for yourself. Don't
become dependent on authoritative references, they can be wrong.

 

[Mark J. McGinty]

Certainly with response.buffer off it will be slower but with response
buffering on I seriously doubt that using inline html would be slower than
a
loop of response writes.

The premise of the linked item above is that multiple calls a
Response.Write
(or Response.WriteBlock) is slower than a single call. However in order
to
modify your code to make a single call you would need to perform string
concatenation in Script. As Michael has already pointed out this is
(relatively at the level we are discussing) pretty slow especially in
VBScript.

There is another factor to consider. String literals encoded in to ASP
Script code will get compiled into the p-code as Unicode strings (these
strings are typically twice as big as they were in the original file).
When
response.write receives this unicode string it needs to perform a
conversion
on the string to the code page current for the response. In line content
OTH will be sent as a block bytes as is in the file no conversion to or
from
unicode will be performed.

Hence I suspect that if you could build a test senstive enough to discover
the differences whilst being sure that other factors are fully accounted
for
(which I doubt can truely be done)

Actually, there is a way, I wrote a small COM object that calls the
QueryPerformanceCounters Win32 API, does the math between start and end, and
casts its returns from 64 bit int to double. It's effective resolution is
equal to the CPU clock speed on modern hardware, thus making it
theoretically capable of timing sub-microsecond intervals (skewed slightly
by COM call overhead, of course.)

It has proven adequate for profiling ASP script code; coincidentally, I
originally wrote it for precisely that purpose.

http://www.databoundzone.com/projects/highrestimer/index.htm


-Mark