🚀 go-pugleaf

In article <9208260507.AA05043@kuwait.lucid> jonl%kuwait@lucid.com (Jon L White) writes:
>
>But much more importantly is to look at SLOT-VALUE in an open-codable
>context; Lucid's implementations  show almost an order of magnitude
>speed up over "naked slot value", and the 4.1 release even obeys all
>the MOP'ish concerns.  This context is usually (1) within the lexical
>scope of a defmethod, (2) object is lexically recognizable as one of
>the specialized parameters, and (3) slot name is compile-time constant.
>[PCL used to have this sort of context-dependent optimization also,
>but without the automated invalidation for MOP'ish concerns.]  

PCL still has this kind of context-dependent optimization.  The new
versions of PCL work the same as the old ones did, only with less
runtime optimization overhead than before (and with MOP-required
automated optimization invalidation as necessary).

And fortunately for programmers using any version of CLOS, this
open-codeable (and very fast) within-defmethod slot-value context
is probably the most common usage, dramatically reducing any potential
slot-access performance penalties CLOS implementations might face in
comparison to implementations using structures.

>Your numbers somehow don't seem to be consistent for this case --
>I get 173,913 on a Sparc2, where you get 35,000 on a Sparc1.  The
>two hardware platforms aren't _that_ much different, are they?

Mea culpa.  I had unequal compiler optimizations.  With the highest
compiler optimization settings, I get 89,000 on a Sparc1.  Thanks
for pointing out the error, and the reminder of the many pitfalls
of benchmarking.

- Trent Lange