Re: compile-flavor-methods for CLOS

[moon@cambridge.apple.com (David A. Moon)]

> Date: Wed, 19 Dec 90 09:22 EST
> From: Qobi@ZERMATT.LCS.MIT.EDU (Jeffrey Mark Siskind)

> I'd also like to comment on CLOS. A while back someone (I think Moon) made
> a claim on SLUG that there was no need for an analog to :ORDERED-INSTANCE-VARIABLES
> in CLOS because experience with Flavors showed that while once upon a time
> that option created a significant improvement in performance, recent enhancements
> to Flavors made the normal case much more efficient so that the performance
> difference was reduced. THAT IS SIMPLY NOT TRUE. I recently took a 5000 line
> program which I am currently writing (which has 19 DEFFLAVOR forms) and changed
> 3 of them to use ordered instance variables (for a total of 28 instance variables
> which were ordered) and my program runs 50% faster. It is an animation program
> whose performance improved from 18 frames per second to 27 frames per second.
> So the relative cost of normal instance variable access to ordered instance
> variable access must still be very high to account for the 50% improvement
> over the entire mix of instructions my program is executing which has only a
> small percentage of instance variable access. This change required adding only
> 17 lines to my program. For this reason alone I think I could not switch to CLOS
> unless CLOS provided some equivalent mechanism.
> 
> Furthermore, currently CLOS compiles methods at run time. Flavors
> COMPILE-FLAVOR-METHODS compiles methods at compile time, incurring neither
> load time nor run time overhead. The bogus solution previously presented
> for CLOS compiles methods at load time. File loading on Symbolics is already
> painfully slow (much slower than on Lucid). Method compilation should be
> done at compile time, not at load time or run time. I can't see *ANY* advantages
> to doing it at load time or run time. Personally, when I use flavors, all
> of my flavors have associated COMPILE-FLAVOR-METHODS.

I'm not sure why I bother responding to mail containing intemperate language, but
I did promise to try to continue being helpful on SLUG.

When :ORDERED-INSTANCE-VARIABLES was first introduced into Flavors
it produced a speedup on the order of a factor of 100.  The speedup is
very much smaller now.  As you found, there is still some speedup.
I'm surprised you found a 50% overall improvement.  Most of the
execution time of your program must be in instance variable reading and writing.
The overall speedup from ordered instance variables in most programs is much
smaller.  I don't have a Symbolics machine here, so I can't measure the difference
between a regular and an ordered instance variable access, but I believe it's
a couple of microseconds for the first access in a method and about a microsecond
for succeeding accesses in a method (XL400).  Perhaps you are calling accessor
functions, rather than accessing instance variables as you said.  If so, the
speed difference is somewhat larger with :ORDERED-INSTANCE-VARIABLES, but type
safety is also lost.

It's possible that if you're getting a lot of benefit from 
:ORDERED-INSTANCE-VARIABLES you would benefit even more from using DEFSTRUCT.

Symbolics is not asking you to convert your Flavors programs to CLOS.  All of
the documentation has been very clear on that point.

It is not true that COMPILE-FLAVOR-METHODS eliminates load-time overhead
in Flavors.  Actually it increases load-time overhead.

The reason CLOS doesn't compile combined methods at compile time is that if the
compile-time environment is different from the load-time environment, the
compilation would have to be done over again at load-time or else incorrect
compiled information would be loaded.  The same issue exists in Flavors,
and at load-time COMPILE-FLAVOR-METHODS checks everything and recompiles as
necessary.  This could be done for CLOS too, but it's a lot of work and was
one of the things that had to be dropped due to lack of resources to do
everything.  If you don't see why this should be difficult, you'll have to
take my word for it, I guess.  I hope you can also understand why implementing
non-standard CLOS features that were not portable to other implementations had
to take lower priority than implementing the standard CLOS language.

I hope you can understand why lashing out at people who try to help you and
calling them bogus decreases their desire to help you in the future.

Sincerely yours, an interested observer.