Re: Continuing comments on Draft 11

[Gregor Kiczales <gregor@parc.xerox.com>]

   Date: 	Mon, 5 Nov 1990 08:32:00 PST
   From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>

   Users defining their own kinds of methods would pay a substantial price
   in performance.  When not using anything in MOP, a call-method in my
   implementation consists of a couple cars and cdrs and a simple function
   call (I do all the METHOD-FUNCTION kind of stuff during method
   combination.  I also know what the arguments look like at that time,
   which is important for things like mapping tables).  The MOP user would
   have to check the list of next methods, and either call METHOD-FUNCTION
   or NO-NEXT-METHOD as appropriate, cons the method arguments into a list,
   etc.  There's mo room for a valid CL compiler to do much optimization
   there either, since argument passing conventions are a cooperative
   effort between the caller and the method being called.  I want MOP users
   to be able to get the same kind of performance they get from the non-MOP
   stuff.

Mumble, meta-level incursions into the actual method dispatch runtime
are bound to cause performance impact.  The current generation of MOP
technology can't do too much about that.  In the next generation, I
believe a more aggressive and explicity use of partial evalutation
techniques will help with a lot of this---imagine doing a MOP for the
current Self implementation.

But, note that even in this proposal, I could have improved things a
lot.  I would just change the code slightly so that CALL-METHOD passed
in a list of method functions instead of methods.