Hi Mikael! On Sun 13 Apr 2008 21:09, "Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
>> > I have heard that in a well-done CLOS implementation, accessors are are >> > generally faster than slot-ref >> > Note that the current implementation *does* > compile in the slot position into this form and indeed *has* the > property which Andy mentions above. I did not realize this. Thanks for mentioning it. I have shied away from GOOPS internals in the past, but every time I have a brush with them I learn something interesting. What is your perspective regarding <foreign-slot>? I wrote a bit about what I did recently in Guile-Gnome here: http://wingolog.org/archives/2008/04/11/allocate-memory-part-of-n I define a class with a foreign slot like this: guile> (use-modules (oop goops)) guile> (define-class <foo> () (bar #:class <foreign-slot>)) guile> (define x (make <foo>)) guile> (slot-set! x 'bar 45) guile> (slot-set! x 'bar 450000000000000000000) Backtrace: In current input: 6: 0* [slot-set! #<<foo> b7dbaa60> bar {450000000000000000000}] <unnamed port>:6:1: In procedure slot-set! in expression (slot-set! x (quote bar) ...): <unnamed port>:6:1: Value out of range 0 to 4294967295: 450000000000000000000 ABORT: (out-of-range) Is this designed to work? It seems that all is still not right, @slot-ref (only used in accessors, not in slot-ref) accesses the slot as a SCM regardless of whether is is a 'u' slot or a 'p' slot. I suppose that part of the dispatch/compilation needs to be made more sophisticated. > Also, SMOB-based accessors would > be more heavyweight with regard to class creation and memory > consumption than the current solution. Regarding memory consumption. Currently, structs are double-cells: one word for the vtable, one for the data, one empty, and one for the "STRUCT_GC_CHAIN", used (please correct me) during GC to ensure that structs are freed before their vtables. This seems to be to be a waste of memory in instances, in that they occupy 4 words when they only need 2. Is it not possible to avoid this? I have puzzled over this for a number of hours, but have not really come up with anything that seems workable, given our lazy incremental sweeping. I suppose another bitvector for structs in the cards would work; you could run through it at the end of marking, and mark all structs' vtables. > In any case, *please* always benchmark changes like this against previous > code. Will work on some benchmarking, I am very interested to see how some of the method dispatch and compilation code works. Andy ps. I'm happy to see you around! -- http://wingolog.org/