[armedbear-devel] CLOS optimizations

[Erik Huelsmann]

On Mon, Oct 12, 2009 at 6:43 PM, Ville Voutilainen
<ville.voutilainen at gmail.com> wrote:
> 2009/10/12 Erik Huelsmann <ehuels at gmail.com>:
>> Profiling one of the performance tests for CL-BENCH which shows huge
>> difference with CLISP, it turned out that our CHECK-INITARGS function
>> in the MOP package is taking 40% of the object instantiation time
>> consumed by MAKE-INSTANCE. After the first invocation, it's possible
>> to replace this function by a lookup in a cache.
>
> I'm not all that surprised that check-initargs shows up with such a
> high percentage. That's what Peter Graves warned about, being the
> reason why the checking has been disabled thus far. I've been aware
> of the need for a cache of some kind, but I'd prefer getting the
> generic keyword argument checking to a working state before doing
> optimizations (well, we can call them performance improvements if
> that sounds nicer :)).

Right. I'm not commenting on the fact that the work done in this area
isn't being done. It's more that I found that -conform expectations-
we're now impacted big time by argument checking.

> We check
> them pretty well for the methods invoked by make-instance, but that's
> about it. We also
> have some other method invocation failures in the ansi-tests.

Right. And while you work on that, I think it's quite ok for me to
work on caching the make-instance arguments, right?

> I am interested in hearing ideas as to how the cache would be keyed
> and what exactly would it contain.

Well, ofcourse, there could be serveral options. One would be to have
the exact list of options provided and the class supplied and check
that for availability in a hash. If it's there, we'd short-cut the
return. If it's not, we're actually calculating what answer should be.

Another option is: cache the valid argument options and check the
current invocation against the cached options. This requires more
computing power and more list traversal upon subsequent calls.
However, the total expected cache size has a lower upperbound in the
second case than it has in the first case.

> I haven't done much design work to tackle this issue yet, all I have
> at the moment is a vague idea of using a mapping from _something_ to the
> set of names of the keyword args in the EMF. It doesn't seem to be a
> single-level 1-to-many mapping, because there may be multiple discriminating
> types that are used for choosing a method, and the
> generic-function name itself is not sufficient either.

As we discussed, you cannot expect the solution for the special cases
of "make-instance" and the other 4 functions to apply to the GF and
its EMFs for the generic case: the CLHS makes explicit exceptions for
these methods.

The general GF case can probably be cached within the GF, keyed on the
dispatch parameters.

> Maybe I'm just missing something simple. EMFs are compiled, so perhaps
> the compilation can create the cache/mapping?

After compilation, the EMFs are added to the GF using the ADD-METHOD
method. i'd say that's about the right time to change/clear caches?

Bye,

Erik.