On Mon, Oct 12, 2009 at 6:43 PM, Ville Voutilainen ville.voutilainen@gmail.com wrote:
2009/10/12 Erik Huelsmann ehuels@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.