Re: [spr35301] make-<some-struct> performance

>>        Hello,

Hi, Didier,

>> I have a question regarding the performance of structure making
>> functions. Suppose I have something simple like this:
>> 
>> (defstruct struct (slot1 1 :type fixnum))
>> 
>> Benchmarking a number of calls to make-struct made me realize that there
>> is no difference between an optimized version:
>> 
>> (declaim (optimize (speed 3)
>> 		   (compilation-speed 0)
>> 		   (safety 0)
>> 		   (debug 0)))
>> 
>> and a safe version:
>> 
>> (declaim (optimize (speed 0)
>> 		   (compilation-speed 0)
>> 		   (safety 3)
>> 		   (debug 0)))
>> 
>> 
>> This is quite different from other implementations I'm testing. I have
>> also noted that there doesn't seem to be any type checking done in the
>> safe version, so for instance:
>> 
>> (defstruct struct (slot1 1.5 :type fixnum))
>> (make-struct)
>> 
>> does not trigger a type error. This is also different from other
>> implementations (and maybe could explain why the safe and optimized
>> versions perform at the same level; because they wouldn't actually be
>> different).
>> 
>> 
>> 
>> Any comment on this ?

I assume that your question stems from a debugging motivation, since
the spec clearly allows Allegro CL's behavior (the defstruct
description page is rife with nods to the implementation, and the term
"implementation dependent" appears in both slot-option descriptions).
I believe that an attempt had been made to fold defstruct in with the
(then) new CLOS object system, and the intention was to view defstruct
not as deprecated, but as something that would take a back seat to
CLOS.

I personally use defstruct quite a bit, but mostly for speed, and it
has been my observation that most of our customers use defstruct for
speed as well; when type checking and especially usage of the MOP to
create special considerations and checking for building lisp objects,
they tend to use CLOS.

I am not adverse to adding optional checking to slot-options, but it
simply isn't a very high priority.  Is it a priority for you?  If so,
make a case.  A workaround is to use CLOS objects, at least for the
debugging phase of your program - with MOP usage it could actually
do much more than any defstruct implementation could do with just a
check for correct type (for example, if you wanted to count the number
of times a slot got a specific type of object).  If you want to go
ahead and try using CLOS for the interrim and defstruct for
production, CLX is one module that provides an example of such an
implementation choice.  I know that our sources have the option to use
CLOS or defstruct, and although I haven't looked at other versions of
the source, I believe that choice was in the sources before the source
sets did any diverging, so I think you should be able to find an
example in any CLX source.

If your comment was just an observation, then I would say that yes, we
do the same high-optimization building of structs under all
circumstances when it comes to slot options, and thus I would expect
our make-<struct> constructors to generally be at the top end in terms
of speed.

Duane Rettig  [email protected] Franz Inc.  http://www.franz.com/
555 12th St.,   Suite 1450,  Oakland, Ca. 94607