Re: reducing lisp programs' size

[kem@prl.ufl.edu (Kelly Murray)]

In article <creedy-1603951745060001@clreedy-mac.mitre.org>, creedy@mitre.org (Chris Reedy) writes:
|> In article <ddyerD5Jnzr.5E8@netcom.com>, ddyer@netcom.com wrote:
|> 
|> > It is true that pound-for-pound, lisp requires more real memory, more
|> real disk,
|> > and more CPU to get the same actual results from a running program.  The trick
|> > is to get a running program.
|> > 
|> > For my money, efforts to reduce a completed lisp program's size by
|> > treeshaking, or fasloading, or making shared libraries are not worth
|> > the effort in modern virtual memory environments.  
|> > 
|> > [more comments deleted]
|> 
|> The problem with "modern virtual memory environments" is that they require
|> real disk space and real I/O capacity to support the virtual memory
|> mechanism.  This usually isn't a problem for a single user workstation
|> with reasonably large amounts of real memory and a large disk.  This will
|> be a problem if you have a system with a number of diskless nodes and/or
|> nodes with small disks that can't allocate large swap spaces.  And, even
|> though additional disk space for a single machine may be inexpensive,
|> additional disk space for a large number of machines (100s to 1000s) can
|> add up to real money.
|> 

These factors are true, but I think the bigger issue is a little different.
In many commercial environments they have a smaller number of big machines that
service lots of users, who typically interface to the big machine
with X terminals or PC's. In that environment, a program that uses "only 4 mb"
of real memory (and wants 20mb of vm) multiplies out quite a bit when you
have 10-100 users on the system running the program.  

So you can't really write a little calendar program that every secretary 
or data-entry clerk working at XYZ insurance company can all use at once.

An OS shared-library for the code portions seems at least a minimum 
way to deal with this, but I think we can do even better. 

-- 
-Kelly Murray  (kem@prl.ufl.edu) <a href="http://www.prl.ufl.edu";>
-University of Florida Parallel Research Lab </a>