Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!unido!tub!net From: net@tub.UUCP (Oliver Laumann) Newsgroups: comp.lang.scheme Subject: Re: what makes scheme? Message-ID: <1460@tub.UUCP> Date: 11 Aug 90 12:27:15 GMT References: <9008031618.AA02461@mailhost.samsung.com> <1990Aug5.175401@sprawl.yorku.ca> <1457@tub.UUCP> <1990Aug10.133859@avahi.inria.fr> Reply-To: net@tub.UUCP (Oliver Laumann) Organization: Technical University of Berlin, Germany Lines: 32 In article <1990Aug10.133859@avahi.inria.fr> colas@avahi.inria.fr (Colas Nahaboo) writes: > Then, when I do a ps -l and I see that elk takes 1600K of memory whereas > xscheme only 300, for me xscheme is smaller. The reason why "ps" shows more than 1000 KBytes is that Elk has a heap of size 1 MByte by default (you can specify a smaller one by means of an option). The rest is the stack and possibly the text size (1000 KByte). By the way, 1600 KBytes is a bit much; on our machines "ps" never shows more than 1250 KBytes. Anyway, I don't see why this should be so important. Isn't the virtual memory behaviour of a program (locality, resident set size) much more relevant than just the plain size? Unused pages get paged out by the operating system when memory runs low anyway. Elk employs a stop-and-copy garbage collection algorithm, which is known to keep the interpreter's locality high. Note that half of the heap (512 KBytes) is never used by the interpreter except during a GC, thus the corresponding pages need only be paged in during a GC run. If you have a program of size, say, 32 MBytes, but it only executes a loop within a single page during its lifetime-- is this a "large" program? Only looking at the output of "ps" is a poor way to judge whether a program is "large" or "small"; you need to do a more careful analysis to come to a useful judgement. Regards, -- Oliver Laumann, Technical University of Berlin, Germany. pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de