String Building

[Giles]

When assembling an HTML string from a database before sending it to the
client (ie keeping the connection as short as possible), adding to an
existing string (strOut=strOut & strNextLine) takes time and can defeat the
object.
Is putting each line into an array, and re-dimming the array by +1 each time
quicker? Is there a better way?
Thanks
Giles

 

[Bob Barrows [MVP]]

When assembling an HTML string from a database before sending it to
the client (ie keeping the connection as short as possible), adding
to an existing string (strOut=strOut & strNextLine) takes time and
can defeat the object.
Is putting each line into an array, and re-dimming the array by +1
each time quicker? Is there a better way?

Depends on the size of the string. For large strings, putting the fragments
into an array and using Join to create the string will usually be much
quicker than concatenation.
However, you are much better off initially dimming the array to the size it
needs to be rather than redimming it every time a string fragment is added,
even if you initially dim it to a size that is larger than what you need.
Repeating the ReDim operation for every string fragment will undo all the
gains you achieved when you eliminated the concatenation.

Bob Barrows

 

[Bob Barrows [MVP]]

When assembling an HTML string from a database before sending it to
the client (ie keeping the connection as short as possible), adding
to an existing string (strOut=strOut & strNextLine) takes time and
can defeat the object.
Is putting each line into an array, and re-dimming the array by +1
each time quicker? Is there a better way?
Thanks
Giles

And if you're really interested in minimizing connection time, look into
using GetRows and GetString:
http://www.aspfaq.com/show.asp?id=2467

 

[Dave Anderson]

Is putting each line into an array, and re-dimming the array
by +1 each time quicker? Is there a better way?

Yes. Array.push() is especially convenient for avoiding this kind of
nonsense.

But I suppose you mean in VBScript. I suspect, as Bob did, that one of the
recordset methods will do what you need.

 

[Anthony Jones]

When assembling an HTML string from a database before sending it to the
client (ie keeping the connection as short as possible), adding to an
existing string (strOut=strOut & strNextLine) takes time and can defeat the
object.
Is putting each line into an array, and re-dimming the array by +1 each time
quicker? Is there a better way?
Thanks
Giles

I guess at the end of all that you would do:-

Response.Write strOut

So why not replace:-

strOut = strOut & strNextLine

with:-

Response.Write strNextLine

Using GetRows as Bob suggests is what will minimise connection time.
(Not that I'm a big fan of GetRows myself <bg> )

Anthony.

 

[Giles]

Anthony wrote:
So why not replace:-
strOut = strOut & strNextLine
with:-
Response.Write strNextLine

Doesn't response.write wait for the client to "acknowledge receipt" ? so a
slow internet connection could keep the db connection open for a long time -
like really ages with some modems / isp's? My server-fuhrer threatened me
with severe whipping for doing that, which is why I changed to making a
string first, closing the conn, then dumping the string. However, now I am
tying up the processor (can't win!).
Bob's suggestion about dimming first (perhaps with a COUNT to ensure the
right size) and GetRows/GetString seems like a top banana to me

 

[Anthony Jones]

Doesn't response.write wait for the client to "acknowledge receipt" ? so a
slow internet connection could keep the db connection open for a long time -
like really ages with some modems / isp's? My server-fuhrer threatened me
with severe whipping for doing that, which is why I changed to making a
string first, closing the conn, then dumping the string. However, now I am
tying up the processor (can't win!).

Like Dave said with buffering turned on then Response.Write doesn't actually
involve actually sending anything. So using Response.Write will avoid the
inefficient allocation/dealloaction of memory that string concatenation
incurrs.

Bob's suggestion about dimming first (perhaps with a COUNT to ensure the
right size) and GetRows/GetString seems like a top banana to me

An initial Redim of the array is unnecessary GetRows returns an array of the
correct dimensions. Hence if performance is paramount then GetRows coupled
with techniques that avoid excessive string concatenation (such as the Join
function or Response.Write) are what you will be needing.

Anthony.

 

[Bob Barrows [MVP]]

An initial Redim of the array is unnecessary GetRows returns an array
of the correct dimensions. Hence if performance is paramount then
GetRows coupled with techniques that avoid excessive string
concatenation (such as the Join function or Response.Write) are what
you will be needing.

Oops, you lost sight of the original problem, which was creating a large
html string. GetRows will quickly get the data into an array, upon which he
can close the connection and process the data in the array. I don't believe
that Join can be used on a multidimensional array ...
If he is now going to build a large string using the data in the getrows
array, then yes, an array initially dimmed to the proper size may still be
the best solution.

However, I am going along with your (and Dave's) earlier suggestion to
simply response.write the string fragments built from looping through the
getrows array, rather than concatenating them before writing them. I was not
sure about the real reason for creating the large string when I wrote my
initial response.

 

[Giles]

However, I am going along with your (and Dave's) earlier suggestion to
simply response.write the string fragments built from looping through the
getrows array, rather than concatenating them before writing them. I was
not sure about the real reason for creating the large string when I wrote
my initial response.

Thanks everyone, insights much appreciated. I guess I had been misinformed
about response.write, and had been making life unnecessarily difficult for
myself.
Giles

 

[Dave Anderson]

Thanks everyone, insights much appreciated. I guess I had
been misinformed about response.write, and had been making
life unnecessarily difficult for myself.

If you are still concerned about keeping connections open, keep in mind that
you can do any of these things (Response.Write, rs.GetRows, rs.GetString,
even the dreaded concatenation) with disconnected recordsets. That will ease
the concerns of your "server-fuhrer".

 

[Anthony Jones]

I am surprised by how poorly the Stream object fared. I don't use it very
often, so perhaps I am using it sub-optimally. I have included the script
I used in my tests below.

That'll be due to the encoding the stream object will be performing on the
string. It doesn't just dump the unicode string given into the storage but
encodes it to the currently selected codepage.

Anthony.

 

[Anthony Jones]

Ah, that makes sense. In that case, I suspect it doesn't check whether the
text needs to be re-encoded before doing so, as explicitly setting the
locale to "en-us" and the Stream object's codepage to "windows-1252"
didn't have any effect on performance.

All strings in ASP are unicode. Setting the Stream object's encoding to
"UTF-16" might make a difference since it shouldn't have to encode the
string.