Date: Wed, 17 Sep 86 16:06 CET
From: Wolfgang Strobl <STROBL%DBNGMD21.BITNET at ucbvax.Berkeley.EDU>
To:   Info-IBMPC at MIT-MC
Re:   Slow Garbage-Collector in BASICA

In Issue 84 KAPLAN@RED.RUTGERS.EDU reports a problem with BASIC's
garbage collector and asks for help:

> I would like to be able to program around this somehow. I have tried
> to avoid using temporary storage for string variables; I name each
> intermediate string result. (Am I making a mistake to do this?) I
Yes.
> thought this would keep the interpreter from proliferating lots of
> intermediate strings and thereby use up storage.

No. It's the other way round: with IBM'S/Microsoft's BASICA
temporaries don't produce garbage, string assignments do.
In order to demonstrate this, run the following short program:
 +------------------------------------------------------+
 I 10 PRINT"Part 1: temporaries don't produce garbage:" I
 I 20 A$="Hallo":N=0:M=0:FS=0:B$="":FS=FRE(0)           I
 I 30 IF MID$(A$,2,3)="all" THEN N=N+1                  I
 I 40 PRINT ,N,FS-FRE(0)                                I
 I 50 IF N<3 THEN 30                                    I
 I 60 PRINT"Part 2: string assignments do:"             I
 I 70 B$=MID$(A$,2,3):IF B$="all" THEN M=M+1            I
 I 80 PRINT ,M,FS-FRE(0)                                I
 I 90 IF M<3 THEN 70                                    I
 I 100 PRINT"Part 3: enforced garbage collection:"      I
 I 110 M=FRE(""):PRINT ,"back to",FS-FRE(0)             I
 +------------------------------------------------------+
This gives the following output:
 +---------------------------------------------+
 I  Part 1: temporaries don't produce garbage: I
 I                 1             0             I
 I                 2             0             I
 I                 3             0             I
 I  Part 2: string assignments do:             I
 I                 1             3             I
 I                 2             6             I
 I                 3             9             I
 I  Part 3: enforced garbage collection:       I
 I                back to        3             I
 +---------------------------------------------+

In a response to the question Mike Scheutzow wrote:

> There is one other thing you should know: Each time fre(0) [or
> whatever command is used to get the amount of unused memory] is
> called, the interpreter *must* do GC in order to be able to reliably
> report the amount of free space.  When you noticed that memory "reset
> to 50K", it was because your program no longer was using it, not
> because GC was performed.
>
> Whatever is happening during that 10 to 15 minutes, it ain't GC.

This is wrong, as You may deduce from the output of the above sample
program. According to my BASICA manual, a call to FRE with a string type
parameter (FRE("") or FRE(A$)) enforces an early garbage collection.
FRE(0) (or FRE(A)) reports the amount of storage, which is not used and
not garbage, without doing any garbage collection.  They suggest to call
FRE("") periodically in Your Program, in order to get more, but shorter
garbage collection delays.

Mike Scheutzows comment may result from experience with an earlier
Microsoft BASIC. Microsoft has changed BASIC's storage handling a couple
of times since its first version of BASIC (remember those 8K-
ROM-Basic's?)

Summary: place DUMMY=FS("") at a frequently visited position in Your
program. You may try IF INITIAL.FS-FRE(0)<5000 THEN INITIAL.FS=FRE("")
too.

Wolfgang Strobl, STROBL@DBNGMD21.BITNET