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 instead.
+ What compilation settings do you use? Maybe SBCL just performs more
checks that you may want to switch off? (Just guessing here.)
+ 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.
> Basically each mm-object of a class descended from mm-metaclass has a
> normal instance %ptr slot which gives an index into our mmap'd
> regions. I guess should play more with allocate-instance and avoid
> initialize-instance. Any wisdom appreciated!
> Unfortunately as all mmap slots are always boundp, we have to munge
> general initialize-instance to set default slot values. This is quite
> unfortunate. Is there a more sensible way of doing this (along the
> of the way structure slots are handled)?
What do you mean by 'munge' (sorry, I'm not a native speaker)?
Note that you can also define methods on make-instance and allocate-
instance, if that helps.
Pascal Costanza, mailto:pc@..., http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium