[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: memory use
- Subject: Re: memory use
- From: "Robert Holmgren" holmgren@xxxxxxxx
- Date: Sat, 28 Jun 2003 10:53:21 -0400
** Reply to message from Harry Binswanger on Fri, 27 Jun 2003
22:56:11 -0400
> I didn't even realize that the ldpm stuff from startup.int sits around in
> memory. I assume that if I move all that into U2, that would reduce memory
> consumption.
If you load those routines onto ordinary S/Gs (which is the equivalent of
loading what XyQuest called [I think] SAVESGT.SGT [or something like that])
then, yeah, of course you're going to reduce Programming memory consumption
dramatically if you append the stuff to U2 instead. Make individual frames for
each routine, give them unique framenames, and just launch like any other frame
in U2. I have a HUGE section of personal programming appended to my U2, after
the big "public" block. When a new U2 comes out, I just define and delete the
public block, replace with the new version, and issue LH to write it
to disk and simultaneously load the whole renewed file, thereby preserving
intact all my private stuff at the end. The bottom line is that these Menu
files or Help files (whatever you want to call them: DLG, U2, etc) are
incredibly economical in their use of memory: each frame is indexed in a pithy
way (just the framename and the byte location within the Help file), consuming
maybe 25-30 bytes for each reference, and that's it. Short framenames use less
memory than long framenames (duh). Launches are blazingly fast, because Editor
jumps directly to the indexed byte location and executes whatever it finds
there -- no rummaging around searching for the frame. It's a very clever
design (Erickson's I mean). We incorporated into U2 some things that DLG
doesn't have, like a safeguard (only works with certain routines though) that
offloads (caches) some data from the buffer onto disk when a certain threshold
of memory consumption is exceeded (14Kb I think at present), in order to
prevent Editor from getting close to an OOM condition (Out_Of_Mem). Because
when you trigger OOM, you're screwed: there's usually no way to get Editor
back on good behavior -- you gotta save your work, quit, and relaunch.
> when I was young and carefree, memory space didn't matter to me. Now I'm
> like the grasshopper looking in, shivering, at the provident ants in the
> winter
That great old Disney cartoon...
-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------