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