Ralf, it was a different issue specific to CMUCL. Performance was just horrible, but it was fixed by calling (mp::startup-idle-and-top-level-loops). SBCL works fine out of the box (there are other issues but not the speed).
Andrew On 4/6/07, Ralf Mattes rm@seid-online.de wrote:
On Fri, 2007-03-30 at 22:57 +0200, Edi Weitz wrote:
On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" <
lispercat@gmail.com> wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!).
Nice... :)
When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I
understand
it's not a big deal, but still I'd like to know what might get in the
way. I
use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
I guess it's the thread switching that takes the additional time.
From tests on my Linux box (using ApacheBench and a localhost
connection) my impression was that serving static files with Hunchentoot wasn't slower than with Apache.
Just as a side note: unless we talk about low traffic/low volume serving i'd expect Apache to be significantly faster than Lisp solutions - once Apache detects that a request serves static files it uses 'sendfile' to shuffle the file content over the network (thus avoiding to read any data at all into userspace only to write it back to kernel space. That does save a lot of time (and context switches)). That's nothing to be ashamed of as a Lisper - Lisp shines when it comes to content generation ;-)
Cheers, Ralf Mattes
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel