Re: MOP question for language lawyers: can you specialize on standard-class

"Tim Bradshaw (as tfb at cley dot com)" <[email protected]> Tue, 26 May 2026 08:55:41 +0100
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]>
On 18 May 2026, at 17:55, Martin Simmons <[email protected]> wrote:
> 
> Why can't the compiler assume that?  If the program breaks the assumption by
> destructively modifying the object bound to a then that is a bug in the
> program.  The same could happen for a cons:
> 
> (locally (declare (type (cons fixnum) a)) ...)
> 
> if you sneakily setf (car a) to something else.

That's true.  I think having the class change is a whole level worse however.

> Yes, slot access in LispWorks takes a performance hit to guarantee
> thread-safety for simultaneous change-class, but also for updating existing
> objects after class redefinition.


The performance hit over structure field access seems to be over a factor of 30 for both SBCL and LW.  This is less than the two orders of magnitude I thought: it's only about one and a half (but my estimates are probably lower than the real cost).

What it means is that, if you're writing a program where slot / field access will or might be performance-critical, then you should not use classes defined with defclass, or should use them only in a way such that they can't easily be later torn out and replaced by structures (so: avoid multiple inheritance, for instance).

(You *can* use generic functions: GF dispatch is pretty quick in my experience.)

So the situation in CL is really now that there are all these compound types: conses, arrays, structures, for which access to fields is really fast.  And there are things defined with defclass for which it's not.

I think that's rather sad.

--tim

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html