From: spoon
Subject: Optimization question
Date: 
Message-ID: <3834ck$da7@franklin.cc.utas.edu.au>
Hi.
	Recently I wrote this stuff for a bloke and was surprised to
find that my major bottle neck in the whole thing was "every". I
presume this is because of its genericity.  Replacing it my own one
list version improved things by 200% (no exageration).

But it took me quite some time pissing around with cmucl's profile
facility to work this out. Basically one function was consing far too
much and I couldn't figure out why.  My question is, is there some
easy way to work out when this is happening?  

I would have thought cmucl would have done better than this. It knew
all the types, surely it can do some sort of optimization here?

--
"I understand thee well enough," said friar John; "but time makes all
things plain.  The most durable marble or porphyry is subject to old
age and decay.  Though for the present, thou possibly be not weary of
the exercise, yet it is like I shall hear thee confess, a few years
hence, that thy cods hang dangling downwards for want of a better
truss. " - Rabelais.  
From: Rob MacLachlan
Subject: Re: Optimization question
Date: 
Message-ID: <388sia$qop@cantaloupe.srv.cs.cmu.edu>
Not optimizing EVERY/ANY, etc. is an efficency hole in CMU CL that others have
fallen into.  There is no efficency note, because efficiency notes are only
given when the compiler knows of an alternative that it is unable to use.  The
compiler simply knows nothing about EVERY.  The reason EVERY, etc., are so
pathological is that the take a variable number of sequence args, thus must in
general construct a list of each pairing of elements and call apply.  It would
be easy to add (see compiler/{seqtran,srctran}.lisp), but we never did.

  Rob