🚀 go-pugleaf

In article <4600.714768355@bbn.com> jmorrill@BBN.COM writes:
>  
>I would add that in my experience, the cost of SLOT-VALUE (and reader
>methods) is often the limiting factor in terms of performance.  Doesn't
>anyone care about slot value?  [...]

I certainly agree that slot access performance is critical to most
programs, probably even more so than method dispatch.  However, the 
benchmarks Jeff used (and posted) paint a bit too negative a picture
of slot access performance.  The problem is that the test of slot
access was embedded within the body of a defmethod, so that its
timing included the overhead of dispatching the method itself.  Even
taking that into account, however, the slot-access performance of
some of the current commercial CLOS's does seem disappointing.

However, high cost slot access is definitely not necessary in CLOS.
Both Rich Harris and I have extensively optimized PCL's slot access
in the newer versions of PCL to the point that it is relatively efficient.
For example, in July 92 PCL, standard slot access within the body of a
defmethod on a specialized parameter essentially takes only a simple
vector reference on the instance's slots vector using the slot's
(pre-computed) index.

This leads to very fast slot access.  To illustrate, here are some
(very approximate) timings using your benchmark on a Sparc 1 in
Lucid 4.0.  The timings from Lucid's 4.0.1 CLOS are included for
comparison purposes (in operations per second):

                                    Sparc 1        Sparc 1
                              |   Lucid 4.0.1  Lucid 4.0/July 92 PCL
-----------------------------------------------------------------------
 1 dispatch, 1 method         |     158,000        84,000
 slot reader method           |     195,000        67,000
 with-slots (1 access)        |      35,000        68,000
 naked slot-value             |      66,000       155,000

Note that Lucid's native CLOS' method dispatch is significantly faster
than PCL's (both for simple dispatch and slot reader methods).
However, given the heavy optimizations of slot access in the new
PCL, slot accesses have a very low cost.  Subtracting the cost
of the method dispatch itself, the actual additional cost of a standard
slot access in a method is even lower:  the real performance of PCL's
with-slots (1 access) is more like: (/ 1 (- (/ 1 68,000) (/ 1 84,000)))
~= 360,000 slot accesses per second.  Additional slot accesses within
the body of a defmethod beyond the first come at even smaller cost.

This is not to pick on Lucid's native CLOS at all;  indeed, from other
benchmarks, many of the commercial vendor's CLOS's seem to have a similar 
low priority on slot access performance.  Hopefully this will be addressed
in their future releases, because standard slot accesses certainly don't
have to have the high performance cost that they often do now.

But to reiterate Jeff's point on the overall performance question: method
dispatch (and slot access) costs are usually very small in comparison
to what goes into the body of the method.  Efficient CLOS implementations
should easily be relatively close in performance to C++ implementations --
and certainly not integer factors slower overall than C++, except in very
unusual circumstances.

- Trent Lange