Miro and I discussed this today, so here is some summarization:
On Sunday, January 10, 1999, Bruce Mitchener, Jr wrote:
>One of the recent changes to the driver has been to adjust the code that
>invalidates the method cache. This change is still in progress.
>
>Currently, the method cache gets invalidated on these actions:
> * adding a method
> * changing the access of a method
> * deleting a method
> * destroying an object
> * changing the parents of an object
>
>With the way that ColdCore currently operates, this has a really negative
>impact on the method cache. Every time a network connection closes, the
>cache is cleared. Every eval command run clears the cache. Every time you
>edit an existing method, the cache gets cleared. There is obviously some
>ground to be gained here.
This remains true.
>I've already made some fixes:
> * If an object that is being destroyed has no children
> or methods, then there isn't a need to invalidate the
> entire cache, only the entries that mention that object.
Okay, this way isn't optimal. Since the object is going away, we know the
object number won't be valid and won't be used again (at least during this
runtime). This means we don't need to invalidate the cache, since the
objnum won't match up in the future. With some of the other optimizations,
it might be interesting to look at the effect of deleting all of the methods
on a leaf-object before destroying it.
> * The method cache only cares about methods that have
> 'frob' access. So, we need only invalidate the cache
> when the access changes from or to 'frob' access.
This is fine.
> * Only invalidate the method cache in deleting a method
> when you actually delete the method.
As is this.
>Things we could do but don't yet:
> * When adding a method to do an eval, and then deleting
> the method, signify somehow that it is temporary and
> should not be cached or affect the cache. This could
> also be handled by potentially adding an eval_method()
> built-in to the driver.
Instead, there is a far better solution. We can use a routine just like
method lookup to go through and invalidate each entry in the cache for this
method on deleting the method. Deleting a method from a leaf-object falls
under this as well.
Adding a method to a leaf-object need not invalidate the entire cache, just
do a lookup on that object itself and invalidate if found. I think we still
need to do a total invalidation on adding a method to a non-leaf object.
Can we use the lookup routine from above to specifically invalidate again?
> * If an object has no children or methods, and is the
> subject of a call to change_parents(), then, you could
> follow a strategy of invalidation similar to that taken
> during the destruction of an object.
I think this is still true, don't know that much more is possible.
> * When editing a method, add_method() is called. This
> invalidates the cache. It then deletes the method,
> which again invalidates the cache. All of this is
> not needed since all we are doing is editing the code
> for an existing method. This should be simple to fix,
> but is just a matter of the time needed.
This can also still be addressed with some code in add_method().
>Am I missing some optimizations? Thoughts on how to handle the eval
method?
>Is there likely to be a problem with one of these changes?
- Bruce
|