|
Ben Wants to Know:
I'm getting conflicting opinions on whether it is better to do loads of
Response.Writes rather than building up a big string and doing one
Response.Write.
I am now at a stage where all my pages are written using Subs/Functions that
utilise Response.Write, I did it this way because I had read/heard that
doing loads of strHTML = strHTML + "data" command is very slow and
inefficient in VBScript.
Any views on this? I admit I have done no time tests (v.busy at the moment)
but if anyone has i'd be interested in the results.
Art Says:
My experience shows that for very long strings, it is *much* faster to do
multiple Writes than to concatenate all the strings first.
Luis Provides:
I hope Ken Schaefer doesn't mind me publishing this, check out this link:
http://www.adopenstatic.com/experiments/stringconcantenation.asp
Tomm Concurs:
I avoid intermixing straight HTML and asp by writting the *entire* page using multipe response.writes....
Arnold Challenges:
A savings of maybe 4%, best vs worst. Useful effort on Ken's part, which
has convinced me to apply my optimization time/efforts elsewhere.
Art Replies:
Huh? 6187ms vs 47ms is a savings of ~99.2%. What are you referring to?
My own experience has shown that changing concatenation to multiple Writes
can change a page that you have to sit and wait for into a page that loads
almost instantly.
Tomm Find an Exception:
The only exception to this rule I've found is when you call a sub from a
sub...then it may not work as well to write from the called sub. I have
timed this type of situation and found concatenation faster in many cases.
It's the only exception I've found so far to the general rule of
response.writing instead of concatenating. None of these strings tested were
over 200-300 lines...
Anders Does a Test:
String-concatenation in VBScript has proven to be slow, if not really slow.
I made a test with a C++ COM object vs. VBScript contatenation.
It was a typical XML string concatenation with 1.000 and 10.000 iterations.
I'm using a lame PII 233Mhz server here (just a little private IIS) for
testing.
1000 iterations:
C++ COM object: 0,03906 secs.
VBScript engine: 1,77344 secs.
VBScript it 45,40 times slower.
10.000 iterations:
C++ COM object: 0,48047
VBScript engine: 363,1797
VBScript it 755,88 times slower.
I know its not likely that you to 10.000 concatenations on a page, but you
get the idea. With XML in particular, every *single* concatenation has to be
as fast as possible because the extra step involved in using XML/XSL comes
with a performace hit.
You can thus allow yourself the luxury of seperating your code from
presentation 100% and get the *same* performance (valid when building
strings of HTML using ASP. Response.Writes of HTML directly can't compete,
ofcourse!)
-- Attached ASP Code --
Option Explicit
Server.ScriptTimeout = 10000
Dim oCat
Dim intI
Dim strXML
Dim timStart
timStart = timer
'## C++ ENGINE
Set oCat = CreateObject("StrCat.Catter")
oCat "<TimerTree>" & vbCrLf
For intI = 1 To 1000
oCat "<TimerNode><![CDATA[TestDataTestData" & intI & "]]></TimerNode>" &
vbCrLf
Next
oCat "</TimerTree>" & vbCrLf
Set oCat = nothing
Response.Write("Test 1: " & Round(timer - timStart, 5) & "<br>")
timStart = timer
'## VBScript ENGINE
strXML = "<TimerTree>" & vbCrLf
For intI = 1 To 1000
strXML = strXML & "<TimerNode><![CDATA[TestDataTestData" & intI &
"]]></TimerNode>" & vbCrLf
Next
strXML = strXML & "</TimerTree>" & vbCrLf
Response.Write("Test 2: " & Round(timer - timStart, 5) & "<br>")
Ben Wants To Know:
Anders, care to share your COM object so I can test on the servers here?
Anders:
Yes, ofcourse I'll share the C++ component. I haven't programmed it myself,
but have given it some thoughts on adding some more functionality to the
class. Also, I don't like the name of the component, but that is only nitty
gritty stuff which everyone else can live with!
Here's the link to the site with the original component:
http://www.4guysfromrolla.com/webtech/092500-1.shtml
These guys deserve great credit. I've just speeded up my backend (really big
Content Management System) by a factor of 3 - 5 depending upon datasizes.
Really impressive - extremely impressive, rather. Issues like this makes one
wonder if there many other issues like this in ASP!
I'll keep this list posted if I change anything - and the original author,
ofcourse!
Paul Throws Some XML into the Mix:
I have looked at this slow string concatenation for number of our
applications
(server-side XML) and found best solution is to limit the string sizes
(because vbs is copying the existing to add the new).
Try changing the loop structure from a 1X1000 iteration loop to a 10 X 100
Something like:
for x=0 to 9
strXML=""
For intI = 1 To 100
strXML = strXML & string_to_add
Next
ostr=ostr&strXML
next
I use this a lot on large XML record assembly and get good results.
Anders Concludes:
This is true. I have found too, that when you're converting recordsets into
XML, the bottleneck is at the data-source (the DB), not the
string-concatenation. This obviously goes for the file-system too. And since
we do a lot of recordset -> XML stuff here, the advantage is not so big as I
could ask for.
This conversation string was taken from the 15Seconds ASP Listserv on 3/21/01. If you have an ASP-related question or
would like to share some of your knowledge with others, you may join the list by clicking here.
|
