Re: High S/Gs

[Carl Distefano cld@xxxxxxxx]

Reply to note from Harry Binswanger  Thu, 02 Sep
2010 13:59:55 -0400

> Thanks for confirming my understanding of how high S/Gs ought
> to work. Thus emboldened, I dug in and found the error (in the
> daughter routine).

OK, good. BTW, how do you know it's a girl?

> To release memory, my strategy now is to have one master
> program that, along with other bells and whistles, has:
>
> BXrun 1.pgmQ2
> BXrun 2.pgmQ2
> BXrun 3.pgmQ2
> BXrun 4.pgmQ2
>
> The theory is that each program will release its S/Gs when it
> returns to the parent program (except for 1 or 2 S/Gs that are
> numbered over 99).
>
> Is this a good way to go?

No, it doesn't solve the problem. S/Gs -- even "transients" in the
range 01-99 -- used by child routines retain their content as long
as the parent routine is running. The memory occupied by that
content is not released until the parent routine has finished.

Here's a simple demo. Save all five PMs (as five separate files) to
the same directory, then:
 RUN 0.PM

The parent program, 0.PM, runs the child programs, 1.PM, 2.PM, 3.PM
and 4.PM, one by one, as in your model above. Each child PM stuffs 1
byte into a new S/G but does not touch the other PMs' S/Gs. You'll
see that, as each child executes, the total length of the test S/Gs
(01-04) increments by 1; ergo, the S/G used by each terminated child
PM retains its content while the parent is executing.

XPLeNCODE v2.0
b-gin [UNTITLED]
;*; 0.PM[cr|lf][BX_]es 1[Q2_];*;[cr|lf];*;[cr|lf];*; Test S/G
s 01-04[cr|lf]{<}SV01,{>}{<}SV02,{>}{<}SV03,{>}{<}SV04,{>};*;
[cr|lf];*;[cr|lf];*; PM number (incremented by each PM)[cr|lf
]{<}SV05,0{>};*;[cr|lf];*;[cr|lf];*; Report total length 01+0
2+03+04[cr|lf]{<}SU06,{<}SX07,{<}VA|01{>}+{<}VA|02{>}+{<}VA|0
3{>}+{<}VA|04{>}{>}{<}SX07,"PM #"+{<}IS05{>}+": len = "+{<}IS
07{>}{>}{<}PR@07{>}[BX_]p[Q2_]{>};*;[cr|lf];*;[cr|lf]{<}GT06{
{062}};*; PM 0 (this routine)[cr|lf][BX_]run 1.pm[Q2_]{<}GT06{>};
*;[cr|lf][BX_]run 2.pm[Q2_]{<}GT06{>};*;[cr|lf][BX_]run 3.pm[
Q2_]{<}GT06{>};*;[cr|lf][BX_]run 4.pm[Q2_]{<}GT06{>};*;[cr|lf
]{<}EX{>}[cr|lf][cr|lf];*; 1.PM[cr|lf]{<}SX05,{<}PV05{>}+1{>}
{<}SV01,!{>}{<}EX{>}[cr|lf][cr|lf];*; 2.PM[cr|lf]{<}SX05,{<}P
V05{>}+1{>}{<}SV02,!{>}{<}EX{>}[cr|lf][cr|lf];*; 3.PM[cr|lf]{
<}SX05,{<}PV05{>}+1{>}{<}SV03,!{>}{<}EX{>}[cr|lf][cr|lf];*; 4
{046}PM[cr|lf]{<}SX05,{<}PV05{>}+1{>}{<}SV04,!{>}{<}EX{>}[cr|lf][
cr|lf]
-nd
XPLeNCODE

There are three ways to that avoid kind of memory load.
1) Don't introduce unnecessary new S/Gs in the parent or child;
rather, reuse -- that is, overwrite the contents of -- existing S/Gs
wherever possible. (This is sound programming technique in any
context.) 2) Don't use child routines; "promote" them to the parent
level and manually issue separate RUN commands for each routine. 3)
For very large data sets, store the data in one or more editable
files, have the PM CAll the file(s) and operate on (edit) the data
in the document window, then SAve the file.

Also, remember that program code itself occupies valuable real
estate in the cramped XPL memory space -- a compelling reason to
keep PMs as small as you can, and to avoid using very large child
programs or subroutines. The children continue to take up space as
long as the parent is still working, yet another instance of art
imitating life.

--
Carl Distefano
cld@xxxxxxxx