shadedecho
Programmer
I have the following VBScript function:
This function takes a binary object, such as that returned from an XMLHttpRequest via the ActiveX control in IE, and converts it to a string representation. It works correctly, but for large objects (say about 67k in size), it takes visibly about 4-5 seconds to execute. It works quite efficiently on smaller objects with only a couple hundred bytes in them.
So, I was attempting to optimize this function. My first pass was to think that maybe a big part of the slowdown is in the looping part, where it's adding character-by-character to the end of the string. I'd read somewhere that IE uses immutable strings (at least in Javascript), so adding to the end of a string over and over again was taking the overhead of re-creating the string each time. In Javascript, one suggested solution to this type of algorithmic slowdown was to gather all the characters one at a time into an array, and then perform a JOIN on the array to make the string once, which is apparently much more efficient.
So, i tried adjusting my function as so:
I should mention, I know the K = K line is probably not necessary, there quite possibly was a way to re-write the J = 0 testing logic properly so as to eliminate this non-op. But I didn't want to mess with that part yet. I just wanted to see if this would work in VBScript the same way a similar algorithm would work in Javascript.
However, to my dismay, the resulting string is twice as long, as somehow this algorithm inserts a space in-between each regular valid character.
What's surprising though is I don't think it's the loop, I think it's the Join() statement. The value of K is the 67000 some odd figure that I'd expect as the normal character length of the string, indicating that the Buf variable was filled with exactly that many characters. I don't know why Join() would be inserting extra ones.
Anyone have any idea what's going on with my code?
Code:
Function bintostr(obj)
Dim I,S
Dim J
For I = 1 to LenB(obj)
J = AscB(MidB(obj,I,1))
If J = 0 Then
S = S & ""
Else
S = S & Chr(J)
End If
Next
bintostr = S
End Function
This function takes a binary object, such as that returned from an XMLHttpRequest via the ActiveX control in IE, and converts it to a string representation. It works correctly, but for large objects (say about 67k in size), it takes visibly about 4-5 seconds to execute. It works quite efficiently on smaller objects with only a couple hundred bytes in them.
So, I was attempting to optimize this function. My first pass was to think that maybe a big part of the slowdown is in the looping part, where it's adding character-by-character to the end of the string. I'd read somewhere that IE uses immutable strings (at least in Javascript), so adding to the end of a string over and over again was taking the overhead of re-creating the string each time. In Javascript, one suggested solution to this type of algorithmic slowdown was to gather all the characters one at a time into an array, and then perform a JOIN on the array to make the string once, which is apparently much more efficient.
So, i tried adjusting my function as so:
Code:
Function bintostr(obj)
Dim I,K,S,L,J,Buf()
L = LenB(obj)
K = 0
ReDim Buf(L)
For I = 1 to L
J = AscB(MidB(obj,I,1))
If J = 0 Then
K = K
Else
Buf(K) = Chr(J)
K = K + 1
End If
Next
S = Join(Buf,"")
bintostr = S
End Function
I should mention, I know the K = K line is probably not necessary, there quite possibly was a way to re-write the J = 0 testing logic properly so as to eliminate this non-op. But I didn't want to mess with that part yet. I just wanted to see if this would work in VBScript the same way a similar algorithm would work in Javascript.
However, to my dismay, the resulting string is twice as long, as somehow this algorithm inserts a space in-between each regular valid character.
What's surprising though is I don't think it's the loop, I think it's the Join() statement. The value of K is the 67000 some odd figure that I'd expect as the normal character length of the string, indicating that the Buf variable was filled with exactly that many characters. I don't know why Join() would be inserting extra ones.
Anyone have any idea what's going on with my code?