Speed theory <%.....%> OR <%.....%>...<%%>....<%....%> 2

[FlatHead]

Client server is cool because client and server will separate the workload between them.

But which one is faster ?
<%
ASP code all at once
%>

OR

HTML
<%asp%>
HTML
<%ASP%>
etc

imagine the following two examples on a large scale project.

DOES IT MAKE ANY DIFFERENCE?

 

[Churchill]

Yes, it does make a difference (so I've read) especially on large pages.

Take the following example. They recommend doing this:

<%
' PULL RECORDS FROM A TABLE AND DISPLAY IN A TABLE ROW
DO WHILE NOT RSData.EOF
Response.Write &quot;<TR><TD>&quot; & RSData(&quot;Field1&quot & &quot;</TD><TD>&quot; & RSData(&quot;Field2&quot & &quot;</TD></TR>&quot;
RSData.MoveNext
LOOP
%>

Instead of:

<%
' PULL RECORDS FROM A TABLE AND DISPLAY IN A TABLE ROW
DO WHILE NOT RSData.EOF
<TR>
<TD><%=RSData(&quot;Field1&quot%></TD>
<TD><%=RSData(&quot;Field2&quot%></TD>
</TR>
RSData.MoveNext
LOOP
%>

There is an even better method for doing this kind of processing, using GetRows or GetString I think it is...but I'm not too well versed in this so maybe somebody else will be able to show an example.

 

[TheInsider]

The first method is faster but in reality all you can really do is simply try to minimize the amount of jumping in and out of script tags as possible.

 

[TheInsider]

The &quot;Instead of:&quot; method that Churchill listed is a good example of what not to do.

 

[Churchill]

from my experience, the most readable method is usually the slowest to process. It's your call whether to make it readable or optimised.

 

[FengShui1998]

It actually depends on what you're trying to benchmark,
the CPU or the network.

In Churchill's response, he has:

<%
' PULL RECORDS FROM A TABLE AND DISPLAY IN A TABLE ROW
DO WHILE NOT RSData.EOF
Response.Write &quot;<TR><TD>&quot; & RSData(&quot;Field1&quot & &quot;</TD><TD>&quot; & RSData(&quot;Field2&quot & &quot;</TD></TR>&quot;
RSData.MoveNext
LOOP
%>

SHOULD BE:

<%
' PULL RECORDS FROM A TABLE AND DISPLAY IN A TABLE ROW
strTmp = &quot;&quot;
DO WHILE NOT RSData.EOF
strTmp = strTmp & &quot;<TR><TD>&quot; & RSData(&quot;Field1&quot &
&quot;</TD><TD>&quot; & RSData(&quot;Field2&quot & &quot;</TD></TR>&quot;
RSData.MoveNext
LOOP

response.write strTmp
%>

If you have large amounts of records, this will reduce network overhead instead of having to do small writes to the browser. But I would definitely stay with

<%
ASP code all at once
%>

Cheers,
fengshui_1998

 

[link9]

Hate to disagree here, but

<%
' PULL RECORDS FROM A TABLE AND DISPLAY IN A TABLE ROW
strTmp = &quot;&quot;
DO WHILE NOT RSData.EOF
strTmp = strTmp & &quot;<TR><TD>&quot; & RSData(&quot;Field1&quot &
&quot;</TD><TD>&quot; & RSData(&quot;Field2&quot & &quot;</TD></TR>&quot;
RSData.MoveNext
LOOP

response.write strTmp
%>

is not faster than:

<%
' PULL RECORDS FROM A TABLE AND DISPLAY IN A TABLE ROW
DO WHILE NOT RSData.EOF
Response.Write &quot;<TR><TD>&quot; & RSData(&quot;Field1&quot & &quot;</TD><TD>&quot; & RSData(&quot;Field2&quot & &quot;</TD></TR>&quot;
RSData.MoveNext
LOOP
%>

Not in vbScript anyway. String manipulation is vbScript's weakest point, and so every time you concatenate and such, it's rebuilding the variable, adding to it, etc... Very slow. Response.write() a bit at a time, while it might be heavier on the network, will make your page function faster.

In truth, I would prefer to do it the first way, and put it all into a function, assign the string to the function, and then you are just response.write(function) to get the output. It really makes for cleaner code, but like I said, it is slower.

paul

 

[FengShui1998]

Paul,

Like I said, it depends on what your trying to benchmark, the CPU or network. I agree that response.write(s) with small data is faster, but it also consumes a large amout of overhead, not good for your network. I think we agree but it depends on where you would like to see your best performance.

fengshui_1998

 

[FlatHead]

thanks a lot everybody. Very informative feedback very cool tips. I hope this will save me time and avoid complaints from the unhappy dudes...