!pr2
!lm12
!rm75
Save Garbage by Emptying Arrays............Bob Sander-Cederlof

As we all know, Applesoft programs which use a significant number of strings can appear to die for long periods of time while "garbage collection" is performed.  Many techniques have been published to reduce the frequency of garbage collection, or reduce the amount of garbage to be collected, or to speed up the collector.

Randy Wiggington published a much faster garbage collector in "Call-A.P.P.L.E.", January, 1981, pages 40-45.  The source code is available in S-C format on the Dallas Apple Corps disk of the month for March, 1981.  (Copies available for $10 from me.)  Randy's speed improvement is gained by searching for the highest 16 strings in memory at once, rather than just the highest one string.  It is much faster, but not the fastest.  The time for collection still varies quadratically with the number of strings in use.

Cornelius Bongers wrote the fastest collector I have seen.  It was published in "MICRO -- The 6502/6809 Journal", August, 1982, pages 90-97.  Corny's method is very straightforward, and has the advantage that execution time varies linearly with the number of strings in use.  His method also has the disadvantage that it does not work if any strings contain any characters with the high bit on.  (Applesoft normally does not generate any strings with high-bit-set-characters, but you can do it with oddball code.)  I typed in the program from MICRO, made a few changes here and there, and found it to be lightning fast.

I installed the linear method in a client's program, and his garbage collection time went from 100 seconds after printing every four lines, to only 1/4 second.  Other changes, such as the one described below, cut the interval of collection to once every 12 lines.

It so happens that strings which are empty do not increase the garbage collection time.  Many times in Applesoft programs a string array is filled with data from a disk file, processed, and then filled with fresh data, and so on.  By emptying the array before each pass at reading the disk file, the number of active strings can be greatly reduced.

One of my programs was like this:  the one that prints your mailing label so that the AAL gets to you every month.  Before reading each file (the list is divided into about 12 different files, based on zip code and other factors), I wrote a loop that set each string in the array to a null string, and then forced garbage collection:

     FOR I = 1 TO NH : A$(I)="" : NEXT : F = FRE(0)

The only problem with this was that the loop takes so long!  About ten seconds, anyway, enought to try my patience.

All the above motivated me to write the following little subroutine, which nulls out (or empties) a string array.  Bongers included an array eraser in his article, which completely released an array; however, that requires re-DIMming the array each time.  My program is faster in my case, and it was fun to write.

The program is listed below with the origin set at $300, so "CALL 768,arrayname" will activate it.  It happens to be fully relocatable, so you can load it anywhere in memory you wish.  You could easily add it to your Applesoft program with Amper-Magic or Amperware or The Routine Machine.

I used three subroutines inside the Applesoft ROMs.  CHKCOM gives SYNTAX ERROR unless the next character is a comma.  I use it to check for the comma that separates the call address from the array name.  CHKSTR checks to make sure that the last-parsed variable is a string variable, and gives TYPE MISMATCH if not.  GETARYPT scans an array name and returns the address of the start of the array in variable space.

If you look at page 137 of your Applesoft reference manual, you will see in the third column a picture of a string array.  (Notice first the error:  the signs of the first and second bytes of the string name are just the reverse of what the book says.)  My program looks at the number of dimensions to determine the size of the preamble (the number of bytes before you get to the actual string pointers).

I use the preamble size to compute the starting address of the string pointers, and the number of bytes of string pointers that there are.  Then a tight little loop stores zeros on top of all the descriptors.

The Applesoft program below illustrates the CLEAR subroutine in action.
