Optimize string handling in VB6 - Part III

Processing strings with Visual Basic 6.0 can get considerably faster if you know the tricks. Part III of this article studies the performance of Left$, Mid$ and Right$ in detail. We learn to quickly examine individual characters with Asc and AscW. We check out the differences between Asc and AscW and also Chr and ChrW. We also see how a badly placed pair of extra parentheses can degrade performance.

Part III of this article goes deep in the specifics of string processing in Visual Basic 6. Read the previous parts to get an understanding of the basics of optimization and how strings work in VB6.

VB6 functions in this article: Asc, AscW, Chr$, ChrW$, Left$, Mid$, Right$.

Left$, Mid$ and Right$

The functions Left$, Mid$ and Right$ are essential in string processing. If you've read Part I of this article, you already know that the string versions ($) of these functions run faster than the variant versions (without $). Since these functions are so important, let's take a deeper look into the various functions, their parameters and what exactly it is in these functions that may slow down your apps.

These functions return a partial copy of the input string (s). The input gets copied to the output in whole or in part. Usually in part.

• Left$(s, n) returns n characters from the start of s.
• Mid$(s, x) returns the rest of s starting with position x.
• Mid$(s, x, n) returns n characters of s starting with position x.
• Right$(s, n) returns n characters from the end of the s.

Note: If the string is too short, the output will be shorter than n.

In this article we will use the following variables:

• s = input string
• n = length of output string (number of characters)
• x = start position for Mid$

Avoid a useless full copy

Quite obviously, if Left$, Mid$ or Right$ return a full copy of the whole of s, there is no point calling them at all. You can as well use s. The following calls are useless:

• Left$(s, n) when n ≥ Len(s)
• Mid$(s, 1) always
• Mid$(s, 1, n) when n ≥ Len(s)
• Right$(s, n) when n ≥ Len(s)

If there is a risk for such calls, test for n < Len(s) before calling these functions.

Performance of Left$, Mid$ and Right$

Now, what are the essential factors affecting the performance of Left$, Mid$ and Right$? Is it the size of input (s), the size of output (n), the position of output (x) or the choice of the function (Left$, Mid$ or Right$)?

To test this, we created a small VB6 program that executed each of Left$, Mid$ and Right$ 5 million times. As input s we used strings of 1, 10, 100, 1000 and 10000 characters. As output sizes, we used n = 1, 10, 100, 1000 and 10000, but no longer than length of s. In addition, we tested whether there is any difference in Mid$ from start-of-string compared to end-of-string.

Performance test results: Left$, Mid$ and Right$

1. Output size (n) dictates speed. The longer the returned string, the slower the functions run.
2. High n equals slow performance.
3. Input size (length of s) has no effect.
4. Middle parameter to Mid$(.., x, ..) has no significant effect when output size is the same.
5. Left$ and Right$ run faster than Mid$. The difference is only significant with small output sizes (1, 10 and 100). With large output (1000 and 10000) the speed difference is negligible.
6. Mid$ with 2 parameters is marginally faster (a few percent) than Mid$ with 3 parameters if output is the same.
7. Left$, Mid$ and Right$ run in O(n) time, where n is the number of characters returned.

In a summary, Left$, Mid$ and Right$ spend their time making a (partial) copy of the input string. Copying is the performance bottleneck. Now, how can we take advantage of these findings?

Guidelines for Left$, Mid$ and Right$

Left$(s, n)       Mid$(s, x)       Mid$(s, x, n)       Right$(s, n)

• Don't copy too many characters. Use as low n as possible.
• Use Left$ and Right$ where you would intuitively use them. Don't use Mid$ instead.
• Replace Mid$(s, 1, n) with Left$(s, n).
• Replace Mid$(s, x) with Mid$(s, x, n) if truncated output is OK. This limits the output size to a reasonable n. Note that this optimization is impossible when you need the end of a string. See next.
• To retrieve the end of a string, Right$(s, n) is fastest, then Mid$(s, x), then Mid$(s, x, n). Note that since the functions take different parameters, accurately computing the parameters may pose an intellectual challenge.
• Where Mid$(s, x, n) returns the end of a string, replace it with Right$(s, n). This change is risky since the calls are not exactly the same. Mid$ may return less than n characters depending on x. Make sure you don't add a bug with this optimization.

Left$, Mid$ and Right$ nested inside Asc or AscW

The functions Asc and AscW are frequently used together with Left$, Mid$ and Right$ to tell what a specific character is. Asc and AscW are indeed good fast functions for this purpose. AscW is actually faster, but we'll go into that a bit later.

In the following, what is said about AscW also applies to Asc.

AscW(Left$(..)) is useless

Don't nest AscW and Left$. It makes no sense. AscW(Left$(s, n)) is equivalent to AscW(s). Since AscW only looks at the first character of s, the call to Left$ just slows down your program without adding anything useful.

AscW(Mid$(..)) considerations

Don't copy too many characters with Mid$. AscW only examines the first character anyway. AscW(Mid$(s, x, 1)) is the best call. Note that if you call AscW(Mid$(s, x)) without the third parameter, Mid$ executes slowly when s is a long string.

Example of potentially slow code:

For x = 1 To Len(s)
   If AscW(Mid$(s, x)) = ... Then ...
Next

The above is better written as:

For x = 1 To Len(s)
   If AscW(Mid$(s, x, 1)) = ... Then ...
Next

The performance difference becomes apparent when s is a fairly long string. If you don't test your program with long inputs, you might not notice the performance problem. Users with long inputs will notice it.

AscW(Right$(..)) considerations

When calling AscW(Right$(s, n)) we need to consider n, the number of characters returned by Right$. Performance problems don't exist when n is small. When s is a long string and n can get large, Right$ should not be used.

This call is unoptimal:

AscW(Right$(s, n))

Replace Right$ with Mid$ that returns one character only. Here:

AscW(Mid$(s, Len(s) - n + 1, 1))

Both calls examine the nth character from the end of s. The first call copies n characters, while the second call copies just one character.

Use Unicode: AscW and ChrW$

VB6 works internally with Unicode. Every string is in Unicode, which takes 2 bytes per character. Unicode makes a developer's life simpler. Unfortunately it doesn't make a VB6 developer's life any simpler! While VB6 uses Unicode for strings, it still uses Ansi for input, output and forms.

Because of historical reasons, many VB developers stick to the good old Asc() and Chr$() unless they intend to write international applications. You don't have to be writing international applications to take advantage of a couple of Unicode optimizations. If you're concerned about speed, use the "wide" Unicode versions of these functions: AscW() and ChrW$().

AscW() is not the same as Asc(). They can return different values for the same character.

ChrW$() is not equal to Chr$() either. They take different parameter values. Alternatively, they can return a different character for the same input value.

The good news for string optimizers is that for characters in the plain old ASCII range (0–127), AscW equals Asc and ChrW$ equals Chr$. Very good! So go ahead and replace Asc with AscW and Chr with ChrW as long as you keep in the 0–127 range, that is, as long as you process plain 7-bit ASCII.

Suggestion: Run Project Analyzer on your code to detect the slower Asc and Chr versions for replacement.

Asc/AscW and Chr/ChrW tables

What if you need to work outside the range 0–127? Differences (bugs) will show up if you mix Asc/AscW or Chr/ChrW outside that range.

The differences are easiest to understand in the form of codepage tables. The following tables show what Asc and AscW return for characters beyond 0–127. If you are not familiar with codepages, English-speaking users and those in Western Europe and Americas will usually use codepage 1252 (Latin I). After the tables we are going to discuss how to convert Asc to AscW and Chr to ChrW, and the problems there are to expect.

(skip tables)

• ch = Character
• Asc = ANSI value of char, specific to codepage
• AscW = Unicode value of char, independent of codepage
• Example using first table: Asc("€")=128, AscW("€")=8364, Chr$(128)=ChrW$(8364)="€"

All characters might not show up on all systems. — Most codepages contain a few unused slots. Such slots may show up as a rectangle, a specific character or a regular character. These tables are intended for a general understanding of how VB6 works. Because of the unused slots, do not use these tables as a reliable source for converters. For an accurate definition of code pages, please see a code page reference. — Chinese, Japanese and Korean codepages have been left out as they use double-byte codes exceeding the 128–255 range.

Converting Asc to AscW and Chr to ChrW

Generally speaking, AscW and ChrW are safer to use than Asc and Chr. AscW and ChrW will perform the same everywhere. Asc and Chr, on the other hand, run differently in different locales. It thus makes sense to use AscW and ChrW for both optimization and internationalization purposes. The good news is that VB6 is fully capable of using all values of AscW and ChrW regardless of the locale. VB6 can handle Russian characters in USA and Hebrew in Greece and there's nothing extra the user needs to install. Displaying, outputting and inputting strange characters may require tricks, but internally VB6 handles all characters just fine. (Internationalization is beyond the scope of this article.)

The problem with routinely converting Asc to AscW and Chr to ChrW is that your code may change in a subtle way, causing new bugs to be inserted. There are two kinds of bugs to expect:

• Bug 1. Asc and AscW return different values, and so do Chr and ChrW. You can get an unexpected value or character after conversion.
• Bug 2. AscW returns a full range of values from -32768 to 32767. For single-byte codepages (i.e. not Korean/Chinese/Japanese), Asc returns values 0 to 255. Thus, many pieces of code expect only 0–255. Make sure your code can deal with negative values and also values exceeding 255. You must use the Integer or Long datatype to store the return value of AscW, whereas your code may have run nicely storing Asc values in a Byte.

If you are working with Latin I codepage (1252), as really many VB6 developers are, the problem characters you need to be aware of are Ansi 128–159. Within this range Asc differs from AscW and Chr differs from ChrW. In ranges 0–127 and 160–255 Unicode equals Ansi. For character values within those ranges converting Asc to AscW and Chr to ChrW should be straightforward and safe, and only make your program more international and faster.

Here are a few examples of how your code may go wrong:

• Asc("€")=128 everywhere else but in the Cyrillic codepage, where it is 136. Best to use AscW("€")=8364 everywhere.
• Asc("½")=189 in the Latin I codepage and some others, but in the Central European codepage, 189 represents the ˝ character. Best to use AscW("½")=189 everywhere.
• Chr$(223)="ß" in the Latin I codepage, but not in most others. Best to use ChrW$(223) to always get "ß".
• Testing whether there is a pound in s="£" succeeds with Asc(s)=163 in many locales. However, it fails in the Central European codepage. Best to test with AscW(s)=163.

As you can see, it's a really good idea to use the Unicode versions, but you must know what you're doing.

Caveat with extra parentheses

When passing strings as an argument in a procedure call, an extra pair of parentheses can lead to making an unnecessary copy of the string. Unfortunately VB6's syntax is somewhat tricky about when parentheses are required and when not. Sometimes parentheses are required while sometimes they are too much.

Consider the following procedure that takes a string parameter by reference. In VB6 there are 2 ways to declare a reference parameter, so we have provided two syntax examples for the same thing:

Sub Process(ByRef s As String) ' Preferred syntax
Sub Process(s As String)       ' Alternative syntax

Let's further assume the procedure doesn't modify s, but only reads its value. The purpose of ByRef (instead of ByVal) is to avoid making an unnecessary copy of s. So far so good. This looks like optimal coding.

Now, is this the correct way to call the Sub?

Process (s)

No! That's bad! The parentheses around (s) are extra in VB6. While they are required in VB.NET and a bunch of other programming languages, in VB6 you can (and should) do without them. Here is the correct way:

Process s

The difference is that s without parentheses is passed by reference, while (s) makes a copy of s.

The syntax is different when calling a function to get its return value. If Process is a function, the correct, optimal way to call it is this:

x = Process(s)

To make a copy of s, you need to add an extra pair of parentheses:

x = Process((s))

If you use the obsolete Call keyword, the correct syntax is:

Call Process(s)

To make a copy of s, you need to add an extra pair of parentheses:

Call Process((s))

Tricky, isn't it!

Summary of string optimization rules

The following table summarizes the optimization rules presented above.

Optimize string handling in VB6 - Part III
URN:NBN:fi-fe201003011417