[VB6] - Faster string functions

The goal of this is to just let you speed up a lot of your procedures without having to change any code (except function names from Left() to StrLeft(), Mid() to StrMid(), etc.).

These functions act the same way as the built-in VB6 functions, but work with the data as byte arrays instead.

For smaller strings, there's really not much point but when working with medium to large amounts of data then these should improve the speed quite a bit.

The functions still return strings so you don't have to work with byte arrays.

I haven't done any tests to see how much of a difference this makes exactly but you should notice when your code is compiled.

The best way to get big speed improvements is to convert all of your data processing to work with byte arrays but that can get really complicated for a lot of "novices" who aren't experienced with byte arrays, so this should be the "next best thing" I hope.

I didn't include a Split() or Join() function as I'm not sure how much of a speed improvement that would bring over the originals but I may put them in there anyway.

This is something I wrote for personal use but some other people might find it useful.

Quote:

---

Originally Posted by DigiRev

The best way to get big speed improvements is to convert all of your data processing to work with byte arrays but that can get really complicated for a lot of "novices" who aren't experienced with byte arrays, so this should be the "next best thing" I hope.

---

That's not completely true. The fastest way to manipulate strings is to never change how big they are. (No concatenating or truncating.) This is one reason byte arrays are so fast; the very idea of using them makes it obvious that you want to avoid redimensioning, since that's so expensive. Thus you end up using efficient techniques, unlike with strings where the dreaded ampersand (&) operator will slow your loops to a crawl.

Converting to and from byte arrays is expensive, so you need the manipulation to be much faster to overcome that. And as it turns out, there isn't a whole lot of speed difference between the following two loops:

vb Code:

For i = 0 to UBound(bytArray)
    bytArray(i) = 65
Next
 
For i = 1 to Len(strText)
    Mid$(strText, i, 1) = "A"
Next

Using the Mid$() function to assign strings is very, very fast, and there's no array conversion overhead. Also note that you can assign multiple characters in one shot using Mid(). For example:

Mid$(strText, 1, 13) = "Hello, World!"

The following link is quite good for optimizing string manipulation:

Optimize string handling in VB6

Manipulating strings using Mid$() is how I've always done it. But I have noticed pretty big speed improvements between even that and using byte arrays (for large data). For small to medium sized strings there isn't much of a difference, and the conversion with StrConv() can actually make it slower.

Quote:

---

Originally Posted by DigiRev

(for large data)

---

Fair point. I stand corrected.

I actually disagree on byte arrays to be faster: it depends on entirely on how you want to access the data. For example, making a loop where you compare character codes you end up with a messy solution with strings, thus byte arrays offer a relatively easy way to make a faster loop. However, with some tweaking you can hack an integer array to temporarily point into the string data, which gives a better performance than byte arrays, especially as no data is to be copied.

Strings aren't bad for large data, either. Left$, Mid$, Right$ and friends work very fast even with larger data - slowness only happens when you use the & operator as that triggers a new string to be created. Avoid that and you're good to go. For an additional speed boost you can use the byte versions, LeftB$, MidB$ and RightB$. These aren't as slow as you'd think.


Anyways, as for the functions you built: they're unusable because they drop to single or multi byte character set, text compare is valid only for English alphabet and I'm pretty sure VB's native versions are still faster. InStr's TextCompare is very slow though, so that one is easy to beat.