READERS' FEEDBACK

---

The Editors and Readers of COMPUTE!

 

Speeding Up Basic
While reading your article "MSX Is Coming" in the January 1985 issue Of COMPUTE!, I was inspired to make a few observations about your bubble sort example. I think these comments would be useful to your readers.
    I realize that your sort was not intended to be an example of optimized code, so please don't take my comments as criticisms. Rather, my comments are intended to point out some of the simple things that we frequently overlook when we're involved in some more massive programming task.
    1. A bubble sort of the type illustrated always floats the largest number to the end of the array. On each succeeding float, the extent of the FOR-NEXT loop can be reduced. This results in progressively faster passes through the loops.
    Example: Change lines 150, 170, and 190 to the following:

    On my VIC-20, this reduces the program execution time from 6:35 to 4:52. This is 74 percent of the previous runtime. A similar time savings should apply to any machine.
    2. If an arithmetic operation must be performed more than twice within a FOR-NEXT loop, the loop will usually execute faster if the operation is performed once and assigned to a variable, then used thereafter within the loop.
    Example: Change lines 150, 170, 180, and 190 to the following:


    On my VIC-20, this reduces the program runtime from 6:35 to 4:37. Note that this change was really beneficial only because the IF con dition usually resolves to true, resulting in the subsequent requirement for three additions whenever it was true. If the IF condition were rarely true, application of the "do the addition once" rule might actually slow down the FOR-NEXT loop, unless the loop contained further statements requiring the same operation.
    3. Generally, the more characters you feed BASIC to interpret, the longer it will take to interpret them. For speed-intensive applications in BASIC, such as sorting, one should make the variable names as short as possible. This lets the interpreter make its decisions slightly faster.
    Example: Same as previous except that J is used in place of K1, and X is used in place of EX:


    On my VIC-20, this reduces the runtime from the original 6:35 to 4:27. But more significantly, it is the same program as my previous example, but is 1 percent faster, just from shortening the variable names.
    I'd also like to comment on another of your articles: "Which Computer Language Is Best?" ["The Beginner's Page," January 1985]. In your commentary on BASIC, I think you overlooked stressing the fundamental aspect of BASIC that makes it so appealing to so many of us-the fact that it normally is available as an interpreter. We can stop the program, make a change in a line, rerun the program, and see the result immediately without having to get bogged down in relinking and recompiling code. This makes it easy to use (which you did acknowledge) and facilitates experimentation, even by children, which in turn facilitates learning. I have worked with compiled BASIC before, and found that it involves the same frustrations in use as any other programming language that cannot be immediately run.

Thanks for the tips. Many readers will benefit from your observations. As we pointed out, the sort program was generic so it could be implemented on many different computers without major modifications. The original version of the bubble sort benchmark is listed at the end of the next letter.