Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!ddyer
From: ddyer@netcom.com (Dave Dyer)
Subject: Re: reducing lisp programs' size
Message-ID: <ddyerD5Jnzr.5E8@netcom.com>
Followup-To: comp.lang.lisp,comp.lang.lisp.mcl
Reply-To: ddyer@netcom.com
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <D5E7Et.7HL@midway.uchicago.edu> <3k3cke$u6@Yost.com> <DAVIS.95Mar14124022@passy.ilog.fr> <3k6u6u$k42@kernighan.cs.umass.edu>
Date: Thu, 16 Mar 1995 17:45:27 GMT
Lines: 28
Sender: ddyer@netcom11.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:17105 comp.lang.lisp.mcl:6657

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.  

Fasloading is essentially sleight of hand - it merely moves the memory
to someplace you don't notice it so easily.

Treeshaking has real effect, but risks introducing bugs, has little
effect on performance, and marginal effect on size.

Building shared libraries can yield real benefits, *if* there are several
lisp programs running to do the sharing.  Most places, its a struggle
to get the first lisp program on the run list.

It is wonderful to be able to download trivially small programs with
wonderful functionality, but that isn't Lisp's niche.

---
My home page: ftp://ftp.netcom.com/pub/dd/ddyer/home.html
or try http://www.triple-i.com/~ddyer/home.html
-- 
---
My home page: ftp://ftp.netcom.com/pub/dd/ddyer/home.html
or try http://www.triple-i.com/~ddyer/home.html
