An interesting but short description of ITA Software's very real-world lisp application: Inside Orbitz.
4. Because we have about 2 gigs of static data we need rapid access to, we use C++ code to memory-map huge files containing pointerless C structs (of flights, fares, etc), and then access these from Common Lisp using foreign data accesses. A struct field access compiles into two or three instructions, so there's not really any performance penalty for accessing C rather than Lisp objects. By doing this, we keep the Lisp garbage collector from seeing the data (to Lisp, each pointer to a C object is just a fixnum, though we do often temporarily wrap these pointers in Lisp objects to improve debuggability). Our Lisp images are therefore only about 250 megs of "working" data structures and code.
I like this peek into the low-level implementation guts of industrial strength lisp code. They have about 10 seconds to search 10^30 fares, and they do it by not consing, looking at the disassembly of every lisp function and using foreign code where neccessary. And it sounds like they are winning in the marketplace.
Also see the slashdot discussion and the Franz article.
A note regarding not consing: I am not sure that it is the guaranteed path to high performance so many people think it is; Lisp garbage collectors are pretty good these days and it might actually be faster for you to generate the garbage and let the GC take care of it, compared to writing your own resourcing code. It's also true that the GC has fewer bugs in it right now than the first version of any resourcing code you are going to write. This post by David Lamkins touches on the issues involved. Anyway, I wouldn't automatically assume resourcing was going to win me any performance in a given situation.
Posted by jjwiseman at January 16, 2002 11:50 AM