jonathon <j_mckitrick@bigfoot.com> wrote:
+---------------
| > (And I don't know what 20M can account for when clisp uses only 4MB).
| 
| CMUCL Lisp has a 22M .core file.
| I tried clisp and switched for some reason.  I forget exactly what...
+---------------

Before I switched to using a mod_lisp-style application server daemon
[in CMUCL, for the speed of the compiled code], I tried using both
CMUCL & CLISP to do traditional CGI scripting. On both, the load time
for my utility libraries (CGI stuff, forms parsing HTML generation,
PostgreSQL interface) was quite slow, so I built a custom image for
each tailored to CGI scripting. To my surprise, the ~23 MB of the
CMUCL image was *not* a performance issue, since it is "mmap()'d" and
not "read()" into memory, and FreeBSD & Linux do a good job of caching
recently-mmap'd read-only files [which is what "mmap(,,,MAP_PRIVATE,)"
gives you, effectively]. In fact, after the first execution, a trivial
CGI script runs slightly *faster* with CMUCL (16-17ms) than CLISP (20-21ms).

[Also note that, compared to a custom image, using a standard CMUCL
image and LOADing the CGI/HTML/PG libraries per invocation *did* carry
a significant penalty, and raised the trivial CGI script time to ~100ms!]

So do some measurements of your own in the application environment
you'll be using before deciding that one image or another is "too big".


-Rob

p.s. As I said, I later switched to the persistent server daemon
approach [talking via a socket to Apache], where the time to use
ASDF to compile/load everything at boot time doesn't matter.
Also, my "LHP" pages are [optionally compiled and] cached on first
access, so repeated references to the same base URL [which can
have varying trailing pathname components and query args] don't
even have to touch the filesystem except to check modification times.

Still, the CGI approach is occasionally useful for "one-off" hacks
and prototyping.

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