Re: MCL support for MOP

[bill@cambridge.apple.com (Bill St. Clair)]

>bill@cambridge.apple.com (Bill St. Clair) writes:
>
>> Adding more MOP support to MCL is on my list of
>> things to do, but it's not very near the top of the list so I'm not
>> likely to do it soon.
>
>I wonder how high the need for MOP support is on the list of typical
>MCL users. Some users are worried about the lack of MCL/MOP features.
>Others, however, (including me) don't really use MOP and, therefore,
>are worried about making trade offs regarding performance and/or
>memory.
>
>Questions:
>
>- what impacts would a full MOP implementation have to MCL in terms of
>  performance or memory?
>  
>- could a full MOP implementation be packaged into a separate module 
>  (sort of like PCL minus MCL)

Top of my head estimates follow. Take with a grain of salt.

I doubt that a MOP implementation will require much extra space.
MCL's entire CLOS implementation is only about 270K of source code
which compiles to less than 100K of fasl files (fasl file size is
usually close to in-memory size) The MOP will probably add another
50 to 100K to the source, so it's likely to increase MCL's in-memory
size by 20 to 50K. Some of this will be swappable, so it will only
take up disk space if you don't use it.

>
>One of the many nice things about MCL is its size compared to other
>Common Lisp implementations. It allows developers to create
>applications able to run on low-end machines. However, If more and
>more functionality is creeping into MCL (maybe partly due to the
>ANSIfication of the Common Lisp clean up process) I wonder how much
>longer this is going to be true.

There are a couple of reasons that MCL 2.0 is bigger than 1.3.
The pretty printer and inspector are included in 2.0, they were
provided as fasl files in 1.3. 2.0's CLOS generic functions cost a
little more space than 1.3's Object Lisp obfuns. We'll probably be
looking into a few ways to reduce the size of MCL (though probably
not for 2.1). Some ideas are:

1) A tree shaker to automagically remove parts of MCL that are
   not used by your application.

2) Make the development environment be optional, or distribute 2
   MCL applications: with & without development environment. Maybe
   even a third application that has just Common Lisp with no
   application framework.

3) One or more shared libraries for the different pieces of MCL.
   This will allow small MCL applications at the expense of some
   large inits.

Feedback please. Do you need these facilities? Other ideas?
The MCL development team has decided that MCL's size is not the
most important thing we have to work on right now, but it's
still important to us.


-----
Bill St. Clair
bill@cambridge.apple.com