Re: MOP and mmap'd manardb
John Fremlin <jf <at> msi.co.jp>
2009-09-07 06:16:23 GMT
Pascal Costanza <pc <at> p-cos.net> writes:
> On 4 Sep 2009, at 13:59, John Fremlin wrote:
>> We (MSI) have just released a development version of our memory mapped
>> MOP database. There's a lot that can be improved with it but it has a
>> test suite and has been bashing stuff out for a while.
>> Object instantiation seems a little slow on SBCL (just my impression
>> compared to Allegro 8.1 -- could be completely wrong) and I wonder if
>> there is something I'm doing wrong?
> Not sure, there could be many reasons.
> However, I can notice a few issues from taking a first look at the code:
> + You define a method on shared-initialize for your
> metaclass. According to the CLOS MOP specification, you are not
> allowed to do that, your program is thus not portable. You have to
> define methods on initialize-instance and reinitialize-instance
Thanks for this input. I wasn't aware of that (it isn't covered in AMOP
as far as I can see). I cargo culted the idea from Elephant. But you are
quite correct according to
It is now fixed and I've pushed the updates. Thanks!
> + What compilation settings do you use? Maybe SBCL just performs more
> checks that you may want to switch off? (Just guessing here.)
Not sure to be honest, I'm starting with a general (proclaim '(optimize
speed)) before the project is loaded
> + Your slot-xyz-using-class methods specalize not only on the
> metaclass and the slot definition class, but also on the object.
> That's redundant, it doesn't buy you anything, since you want
> instances of the metaclass to inherit from the object class anyway.
> Leaving out the specialize may allow SBCL to use faster caches.
That makes sense, I'll do that.
>> Unfortunately as all mmap slots are always boundp, we have to munge
>> the general initialize-instance to set default slot values. This is
>> quite unfortunate. Is there a more sensible way of doing this (along
>> the lines of the way structure slots are handled)?
> What do you mean by 'munge' (sorry, I'm not a native speaker)?
I mean that the way I do it is not at all nice and pretty. I think it is
probably clearer to show the code
(defmethod initialize-instance :before ((instance mm-object) &rest initargs)
(declare (optimize speed) (dynamic-extent initargs))
(cond ((eq '%ptr (first initargs)) ;;; XXX this is for speed; if %ptr is given it must be first
(setf (%ptr instance)
(let ((class (class-of instance)))
(setf (%ptr instance) (mm-metaclass-alloc class))
;;; XXX this is a horrible hack because we don't support unbound slots
;;; not in shared-initialize because that is more likely to destroy the system's optimizations????
(let ((slot-definitions (class-slots class)))
(loop for s in slot-definitions do
(when (and (slot-definition-memory-mapped s)
(unless (get-properties initargs (slot-definition-initargs s))
(setf (slot-value-using-class class instance s)
(funcall (slot-definition-initfunction s))))))))))
> Note that you can also define methods on make-instance and allocate-
> instance, if that helps.
The situation when most instance creation occurs is when an object is
instantiated from the database into a Lisp object (generally with one
slot, (hopefully) a fixnum "mptr").
It is possible for the object to have normal instance slots (caches or
temporary slots). Those should be initialized according to the normal
rules. It would be possible to generate an compiled function to do this
explicitly for all such slots -- firstly calling allocate-instance(?)
directly and then the init-functions for each slot.
One approach I was considering was to inherit from structure-class
instead of standard-class, etc. This would finesse the initialisation as
structure slots are also never unbound. But I think that is not really
portable? (And perhaps not sensible)
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july