This is getting completely out of hand! It's time for some facts.

All simple variables in Applesoft take up 7 bytes. In the case of a string
variable, the size of the current contents of the string has to be added to
get the overall storage usage (unless the variable points to the string
constant in the program itself).

A string pointer variable looks like this:

Byte 0-1: Name (only the first two bytes are stored)
Byte 2  : Length (one byte!)
Byte 3-4: Address of the string characters
Byte 5-6: Unused (set to zero)

Note: String array elements are only three bytes each as each element
doesn't have to store the name and the padding bytes. The array header is
5+N bytes plus where N is the number of dimensions.

Since the length is stored in a single byte, the maximum length of a string
is 255 bytes. Note that this is just a MAXIMUM string length, not the size
of each string in memory!

In terms of the potential storage savings, remember that each string
constant takes up N+2 bytes (where N is the length of the string plus two
bytes for the quote characters), while each string variable takes up N+7+V
(where V is the length of the variable NAME itself, eg. B$, XYZ$). Note: I'm
mixing program area and variable area storage savings here!

There are several benefits to using string variables instead of constant
strings:
- Reduced storage (assuming all occurrences of a given string add up to more
than 7 bytes)
- Increased speed (the interpreter doesn't have to parse the entire string
each time it is used, just the two or so bytes for the variable name). This
becomes especially important if the string is generated from other strings.
- Better documentation and program maintainability (having all the strings
in one place makes it easier to check them or change all uses of a string).
Also good for non-printable strings, eg. D$ = CHR$(4).

Having said all of this, if you just BLOAD something at the start of a
program, there's no great benefit in going out of your way to create a
string variable for the BLOAD statement, except maybe for consistency as I
mentioned in the previous point.

As others have pointed out, the actual string data is stored from HIMEM:
down (except where the string data is part of the program). When a string is
copied or modified, the new string data is created and the address in the
string variable is adjusted to point to the new string. The old string data
remains in memory until free storage is exhausted or the FRE(0) function is
called. All the string data is compacted in memory by overwriting the
now-unused string data, leaving the maximum possible space for new strings.
(If any!)

Note: String garbage collection is relatively slow, sometimes significantly
so. The usual recommendation under DOS 3.3 was to explicitly call the FRE(0)
function every so often to try to avoid getting a large buildup of unused
string data. Under ProDOS, the "quiet recommendation" became a "roar of
encouragement" as the garbage collection routine was rewritten to be
massively faster. However as the new code is now part of BASIC.SYSTEM the
required call is PRINT CHR$(4)"FRE" instead of something like X = FRE(0).

-- 
Peter Watson
-- Write to MSDOS disks on the Apple IIgs?
-- Impossible!  ;-)


"The Wizard of Oz" <wizard@emeraldcity.gov> wrote in message
news:pan.2004.01.05.19.27.59.932901@emeraldcity.gov...
> On Mon, 05 Jan 2004 01:38:15 +0000, Simon Williams wrote:
>
> > Disclaimer: I originally posted this a couple days ago, but it seems to
> > have disappeared somewhere in cyberspace.
> >
> > I'm wondering about the efficiency of using string variables in
> > Applesoft. I generally use things like BL$ = "BLOAD", BS$ = "BSAVE", C$
> > = "CATALOG" etc to keep my program lengths down to a minimum. I seem to
> > recall reading that string variables use a fair chunk of memory. If so
> > it may well be a very inefficient practice to assign the variable and
> > then only use it once or twice in the program. Any thoughts on this?
> >
> > -sw
>
> Perhaps the others can correct me here. I think Applesoft string
> variables take up 253 bytes in the RAM. However, I suspect access is a
> little faster than having them as constants.
>
> In terms of efficiency... It all depends what you are doing and how many
> files you are opening. If it's one file then you can make the file name
> part of the string. Also if you are calling the commands multiple times
> (totalling more than 253 bytes each) then it is better to store the
> commands as variables. Conversely, a small program will not suffer by
> having them as constants or variables.
>
> Later
> Mike
>