Newsgroups: comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news4.ner.bbnplanet.net!cpk-news-feed2.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!news-peer.sprintlink.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Message-ID: <DxHnx7.xp.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <322f1671.44808029@news> <8gd900wrpr.fsf_-_@galapagos.cse.psu.edu> <ey3zq30yodk.fsf@staffa.aiai.ed.ac.uk>
Date: Mon, 9 Sep 1996 23:29:31 GMT
Lines: 25
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:22643 comp.lang.scheme:16797

In article <ey3zq30yodk.fsf@staffa.aiai.ed.ac.uk> Tim Bradshaw <tfb@aiai.ed.ac.uk> writes:
>* Scott Schwartz wrote:
>
>> I beg to differ.  Hiding bloat in a dynamically linked library is
>> unhelpful if very many of those pages need to be touched at * runtime,

*If*, with no evidence that the potential problem is actual.

>> even if they are shared with other processes.  DLLs are
>> counterproductive because they delude people into thinking that their
>> executable is small, when in fact its working set is very large, with
>> the concommitant poor performance that people expect from Lisp.

No "if".  Just the completely unsupported claim that DLLs delude
people.

>But C programs do this now.  As far as I can see *everything* on Suns
>(solaris 2.5) is linked with 750k of shared library, and anything that
>does networking is 2meg and stuff that talks to X is 3 up.  Lisp is
>bigger still, but not *that* much bigger. (And of course, these vast C
>programs don't perform that well either).

Suns, though: who cares?  Not Gatesland, don't you know.

-- jd
