Message from discussion Very poor Lisp performance

Path: g2news1.google.com!news4.google.com!news.glorb.com!uio.no!newsfeed1.funet.fi!newsfeeds.funet.fi!news.cc.tut.fi!news.helsinki.fi!not-for-mail
From: Juho Snellman <jsn...@iki.fi>
Newsgroups: comp.lang.lisp
Subject: Re: Very poor Lisp performance
Date: 13 Aug 2005 18:31:27 GMT
Organization: University of Helsinki
Lines: 27
Message-ID: <slrndfsf3v.p65.jsnell@sbz-31.cs.Helsinki.FI>
References: <42fd4459$0$97104$ed2619ec@ptn-nntp-reader03.plus.net> <HvSdnayKD_1M8mDfRVn-ow@speakeasy.net> <42fdd7a8$0$97130$ed2619ec@ptn-nntp-reader03.plus.net>
NNTP-Posting-Host: sbz-31.cs.helsinki.fi
X-Trace: oravannahka.helsinki.fi 1123957887 3622 128.214.9.99 (13 Aug 2005 18:31:27 GMT)
X-Complaints-To: abuse@helsinki.fi
NNTP-Posting-Date: 13 Aug 2005 18:31:27 GMT
User-Agent: slrn/0.9.7.4 (Linux)

<use...@jdh30.plus.com> wrote:
>>> My system is an unladen 900MHz Athlon T-bird with 768Mb RAM running Debian
>>> testing with SBCL 0.8.16 and CMUCL "19b-release-20050628-3 + minimal
>>> debian patches".

That's a rather ancient version of SBCL, you might want to upgrade.
For example:

> (defstruct (vec (:conc-name nil) (:constructor vec (x y z)))
>   (x 0.0 :type single-float)
>   (y 0.0 :type single-float)
>   (z 0.0 :type single-float))

This is using about 2x the memory of what you'd expect for each
instance, and doing an extra memory indirection for each slot access.
Proper support for storing the floats "raw" in the struct was added in
0.9.2 by David Lichteblau.

Another possible pitfall on older SBCLs (<0.8.21) is that they don't
honor the compiler policy for code entered on the repl, but compile it
with low speed, high debug/safety. If you've been pasting the code
into the repl instead of LOADing it, performance would indeed be
horrible. 

-- 
Juho Snellman
"Premature profiling is the root of all evil."