Robert Bruce Carleton  <rbc@hakuhale.net> wrote:
+---------------
| Do you think clisp would have a smaller memory footprint than cmulisp.
+---------------

Perhaps, but it would have a *far* higher CPU "footprint" (assuming the
bulk of the app were compiled). Besides, as I said, the real memory
footprint of CMUCL is much more reasonable than its apparent one.
and you can tune its GC if you like to trade off memory versus CPU
used. Specifically, as distributed CMUCL does a GC whenever the heap
has grown by 12 MB since the last GC finished, but you can tune that
down to GC more often (at the cost of more CPU) or up to lessen the
CPU load. You probably want to set it so that you can get at least
"a few" web hits between GCs for whatever kind of application you're
doing. For example, with the main app I'm currently working on, which
does database queries with 10-100 rows or results and generates HTML
pages with tables of the results on the fly, I seem to get ~25 hits
between GCs using the default 12 MB delta threshold. And those are
the "cheap" generational GCs, which almost always recover almost all
of the memory that was allocated since the last one. So the dymamic
heap used (which is in addition to the 20+ MB of startup code/image)
tends to cycle between ~5 MB and ~20MB, say. [There's a bit of slop
depending on when higher-generation GCs get done.]

+---------------
| If so, would it still get the job done for server side lisp applications?
+---------------

One point to consider is that CLISP has classically been single-threaded,
which can block other users if one user on a *sloooowww* Internet connection
asks for a page that generates a lot of output.

The Apache proxy support that Dan mentioned (in connection with Araneida)
can help this, since Apache will accept all of the output quickly into
the proxy cache, and then dribble it out to the user, doing the rate-
matching for you. [I think...]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607