[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compilation of methods per class.
- To: lange@CS.UCLA.EDU
- Subject: Compilation of methods per class.
- From: Peter Benson <firstname.lastname@example.org>
- Date: Tue, 25 Sep 90 08:39:40 PDT
- Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, cloops-arisia@arisia.Xerox.COM, commonloops.PARC@Xerox.com
- In-reply-to: Trent Lange's message of Tue, 25 Sep 1990 04:07:35 PDT <90Sep25.firstname.lastname@example.org>
From: Trent Lange <lange@CS.UCLA.EDU>
To: Gregor Kiczales <Gregor@parc.xerox.com>
<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.