scsh-users
[Top] [All Lists]

More on scsh bloat

To: schwartz@galapagos.cse.psu.edu, scsh@martigny.ai.mit.edu
Subject: More on scsh bloat
From: shivers@ai.mit.edu (Olin Shivers)
Date: Fri, 3 Nov 1995 08:52:31 -0500
Reply-to: shivers@ai.mit.edu
   : galapagos; ./scsh
   Scsh 0.4
   > (run (sps -l))
   Ty User     Status Fl Nice Prv  Shr  Res %M  Time Child %C Proc# Command
   pb. *       CHILD           96+  72  152  0   0.4+ 88.1  0  2190 /bin/rc
   pb.  |      CHILD         9868+ 628 2640  4   1.1        2  2286 ./scsh

   More than 10M for one instance of scsh, eh?  That's more than one
   order of magnitude larger than perl, and two orders of magnitude
   larger than rc.  My machine has 16M, which means I can run at most one
   scsh before paging begins.

   I just can't understand this.  I used to use a full blown Common Lisp
   compiler, kcl, that was considerably smaller than scsh!  Where's all
   the space going here?

I can't understand it either. Something is way wrong here. Perhaps
your default heap is set too high. Try running scsh with smaller
heaps, and see how low you can go.

   Scsh would be more usable if there were multiple toplevel drivers
   for its various modes.  Something like:

      scsh-interpreter foo.scm
      scsh-byte-compiler foo.scm -o foo.image
      scsh-compiler foo.scm -o a.out

   The first would be an interactive system that would be small enough to
   write shell scripts that don't need or want to be compiled.  In
   principle a small byte code compiler (like perl has) would work here,
   but a 10M monster is a non-starter.

   The second would be a batch mode byte code compiler, like scheme48
   has, so you can generate application images which omit all the
   superfluous stuff from the standard runtime system.  I've been told
   that the scheme48 vm is small; well, then I want to be able to write
   small object files for it to run.

   The third one would be a batch mode native code compiler.

Not a chance. Look -- this isn't a scsh issue. It's a Scheme 48 issue.
Scheme 48 doesn't have a read-eval-print loop. It compiles *everything*.
It has a read-compile-run-print loop. So there *isn't* an interpreter.

When you dump out a heap image with dump-scsh-program, you only get what you
need to make your specified top-level procedure go -- the compiler is left
behind, for example. So if you want a small program, flush the debugging
tables, and dump an image.  That is sort-of like one of your choices above.

Brian and I have discussed distributing two different heap images.
One would have all the debugging tables and the S48 extras pre-loaded --
a comfortable development system. One would be stripped down, for
executing shell scripts.

In any event, those 10Mb are not being taken up by the compiler.
The compiler is a bone-stupid, simple, simple compiler. I don't
know what is tying up those 10Mb, but the compiler is probably
more or less equivalent to perl's.

In principal, I totally agree with you. One of the main reasons I chose
S48 was my belief that a byte-code system would make for small, lean
& mean programs. I had dreams of running on little portable devices,
so I cared about memory footprints.

Clearly, we have drifted off the path a little...
    -Olin

<Prev in Thread] Current Thread [Next in Thread>