[comp.sys.next] memory usage

scott@mcs-server.gac.edu (Scott Hess) (04/28/91)

In article <7e1G6bu.1@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes:
   In article <SCOTT.91Apr27094820@texnext.gac.edu> scott@texnext.gac.edu (Scott Hess) writes:
      8MB RAM is still going to be a plus.  The main reason people
      should have 16M on a NeXT is because DPS takes up alot of RAM!
      Right now, I've not got much running on my NextStation (Stuart,
      Edit, Background, IconBounce), so there shouldn't be too
      many windows, right?  The RSIZE of windowserver from ps aux
      reports 2.74M, the VSIZE 20.0M.  So more RAM would be a plus.
      Besides, RAM is getting cheaper as we speak . . .

   The output of ps has to be wrong.  Look at the values for csh on the
   NeXT.

I agree that it is misleading, but I've found for processes using a
lot of data, it's fairly good.  Awhile back I was testing some new
memory management routines for Stuart, and the basic idea was that
they were supposed to use somwhere around 1/2 of the VM the old
stuff used.  I kept finding that the difference was more like 4/5
of the usage - but I knew that my overhead was less, and combining
that with malloc overhead should make the win be greater (the new
stuff doesn't use malloc in places the old did).

Anyhow, what I found was that running Stuart and not generating any
output left me with a VSIZE about 2x the size of the executable.  I'm
not really sure what to make of this - Stuart is a NextStep app,
so I don't really have a lot of control over what the AppKit is
doing with memory, but in this case it shouldn't be much - the menus,
and a window should be fairly small.

But, to get to the point, once I'd accounted for the apparently
bloated starting size, the memory usage reported by VSIZE was
almost exactly what I had expected.  So, apparently VSIZE has at
least some meaning in the real world!

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer	GAC Undergrad
<I still speak for nobody>
"Simply press Control-right-Shift while click-dragging the mouse . . ."
"I smoke the nose Lucifer . . . Banana, banana."

melling@cs.psu.edu (Michael D Mellinger) (04/28/91)

In article <SCOTT.91Apr27094820@texnext.gac.edu> scott@texnext.gac.edu (Scott Hess) writes:

   I'd still want a disk drive.  Makes it much easier to do software
   updates - remember that NextStep1.0 couldn't do -NXHost to a
   2.0 system, so those would be needed even in the windowserver.
   8MB RAM is still going to be a plus.  The main reason people
   should have 16M on a NeXT is because DPS takes up alot of RAM!
   Right now, I've not got much running on my NextStation (Stuart,
   Edit, Background, IconBounce), so there shouldn't be too
   many windows, right?  The RSIZE of windowserver from ps aux
   reports 2.74M, the VSIZE 20.0M.  So more RAM would be a plus.
   Besides, RAM is getting cheaper as we speak . . .

The output of ps has to be wrong.  Look at the values for csh on the
NeXT.

USER       PID  %CPU %MEM VSIZE RSIZE TT STAT  TIME COMMAND
melling   3204   0.3  2.3 1.34M  384K p8 S     0:01 -csh (csh)

-rwxr-xr-x  1 root     wheel     106496 Oct 22  1990 /bin/csh*


Now compare this with tcsh a SPARC station running Sun OS 4.1.

USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
melling   1840  0.0  2.4  128  264 p1 S    06:27   0:01 -tcsh (tcsh5.18)

-rwxrwxr-x  1 flee     staff      212992 Jul 17  1990 tcsh5.18*


sunws8<!>% size tcsh5.18
text    data    bss     dec     hex
188416  24576   17008   230000  38270

sunws8<!>% file tcsh5.18
tcsh5.18:       sparc demand paged dynamically linked executable

Now tcsh contains a lot more features than NeXT's version of csh(CMU
shell), and it doesn't take up nearly as much memory on the Sun.
Notice that it is also using shared libaries.

So what gives?

Eric Scott told me that using /usr/etc/vmmprint would give me the
answer, but I haven't really looked at it yet(I noticed that there
isn't a man page for it).

-Mike