Announcement

**Lance Edmonds** · 8 Oct 2001, 03:25 AM

This is a little difficult to explain clearly, but it primarily depends on variable scope.

All LOCAL scope variables (including arrays, etc) are deallocated automatically when their owner Sub/Function exits. No problem for you there as the compiler handles this automatically, however, clearing local string variables inside a Sub/Function can be important if the Sub/Function is running in low memory conditions... basically you should aim to keep only those strings that are important in subsequent portions of the code.

There is good reason to clear unwanted string variables in the "main" portion of the code (ie, these LOCAL to the main section), as this helps keep the string segment usage as low as possible, and allows for better automatic string segment reuse (and compaction with MEMPACK). Same applies to dynamic and huge arrays, and the string content of static dynamic string arrays.

If shared or static string contents are not going to be used again, then clearing them also help keep memory usage down.

However, numeric variables occupy a fixed memory location regardless of their value (but only for the life of the variable, ie, it's scope), so in your example above, setting I& to zero achieves nothing as far as memory consumption is concerned - the storage for that long integer remains allocated.

The string segments are a little complex to explain (and my memory of their inner workings is a little rusty!). However, lets assume that you are using the default $STRING 32 setting, and you allocate two 10Kb dynamic strings, A$ and B$. Both of these will fit into a single string segment, leaving approx 12Kb free in that segment.

Now lets allocate a third string (C$) of 16Kb. Since this won't fit into the 1st string segment, a new 32k segment is added, and the string is placed in that segment, leaving approx 16Kb free in that segment.

Next we allocate a fourth string of 14kb (D$). It wont fit into the 12 kb free in the 1st segment, but does fit into the second segment.

Finally, we'll clear A$ and C$. This leaves 10kb free at the lower portion of the string segment, 10K in use in the middle and 12k free at the top; plus 16Kb free at the bottom of the second segment, 14kb in use in the middle, and around 2k free at the top.

In this instance, we have two 'fragmented' string segments. What we need to do is some garbage collection - the compiler does not do it automatically, since that would cause serious and often unnecessary impact on performance. Rather, we can handle it ourselves.

If we issue a MEMPACK at this point, then the compiler moves all the allocated strings back to the beginning of their respective string segments, but this still leaves two partially-used segments in use. What we'd prefer is just one, since the remaining strings will fit into one segment.

So how can the string in the second segment be "moved" back to the first string segment? Allocate it to itself, with D$ = D$.

This leaves us with one string segment in use, containing the 10K string B$ and the 14K string D$, plus approx 8kb free.

Hopefully this should give you some idea why choosing the right $STRING setting can make a difference to memory consumption.

For example, if you use $STRING 4 and create a lot of 3Kb strings, then you'll be wasting approx 25% of the consumed string segments, since you'll only be able to store one string in each segment. In this case, using $STRING 32 gives you the most efficient use of the string segments, since the amount of "slack space" is roughly 2Kb per every 10 strings, or 2/32 = 1/16 slack space to utilized space.

Of course those small areas of unused string segments can be used by smaller strings, but that would depend on what your application is doing - it may or may not need to use a lot of smaller strings.

Whew!

I hope this helps and does not confuse you...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Announcement

Variable Question

Variable Question

Comment