Compilation of methods per class.

[Peter Benson <pab@lucid.com>]

   From: Trent Lange <lange@CS.UCLA.EDU>
   To: Gregor Kiczales <Gregor@parc.xerox.com>
   cc: commonloops.PARC@Xerox.com
   Message-ID: <900925.110735z.10208.lange@lanai.cs.ucla.edu>

   <Gregor's description of how PCL method combination is implemented>

   This indeed looks like the kind of code that I was hoping was generated.
   However, it doesn't seem to explain the kinds of running time I get on
   method calls in generic May Day PCL running in both Lucid and Franz lisp.

   Whenever I have the same method defined for several different classes
   and call the method at least once for instances of each of those classes,
   the time PCL takes to execute the method call goes up, sometimes
   dramatically.  Having the same method defined differently on just four
   different classes generally almost doubles the amount of time taken when
   it is only defined on one class.  The increase in time taken also increases
   when auxilary methods are used (even for classes which inherit no auxilaries) or
   when classes have primary methods that are overridden.  For one particular
   method in my program that has a total of about 20 different primary and 
   auxilary definitions on different classes, and which uses those
   definitions in various mixin combinations on the runtime classes, the
   basic method call takes five times as long as it does when it is
   defined one only one class.

I don't know exactly how you did your timings.  It is important to
understand that the the effective method functions a computed lazily in
PCL.  That is, effective methods are not made until the generic function is
called the first time.  That's so you don't make lots of effective methods
that apply only to intermediate states.  When timing things in PCL make
sure you call each relevant generic function at least once before you get real
timings and after any changes to the class hierarchy or adding new methods.
I think there is a function in PCL that will eagerly create all the
effective methods, but I can't remember the name.  You could call that
function before doing timings to get reliable number too.
If the timings still slow down considerably either the generic functions
are getting invalidated at runtime (adding methods, redefining classes, and
some other things can cause this) or there is a real problem.  It really
should work the way Gregor described it.  

-ptr-