lookupMethodInDictionary hash hit ratio issue?
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Mar 6 02:03:32 UTC 2001
> >What is interesting here is the ratio of probes to calls is 1.91. I
>>would have expected say 1.1. I think this implies the current hash
>>isn't quite as good as it should be? So does anyone have some
>>thoughts on this?
>
>John -
>
>I think your expectation of 1.1 is for a single method table, in
>which you expect to find a hit. But *many* message lookups fail as
>the VM goes running up the superclass chain. That is why the method
>cache is so important. If you're expecting failures, then you can
>get close to 1, but you need a much sparser dictionary to achieve
>it. There's no doubt you can improve this statistic, but it will
>make the image larger. We've always leaned toward close packing
>becuase the method cache does a pretty good job of short-circuiting
>this lookup. It's been a while since I checked, but it used to give
>better than a 95% hit factor. There again, you will find a slightly
>high probe ratio, but in that case it is due to an algorithm that
>allows for easy selective removal.
>
>Hope this helps
>
> - Dan
Yes. I've overlooked the issue that it needs to run up the superclass
chain, thus invalidating the statistics I had gathered. That then
explains the odd numbers I saw saw which I couldn't explain.
For lurkers. In another note I had posted privately to Dan was regard
to a change I've made to flushMethodCache to flush entries based on
if it is a full, or incremental garbage collection event. This avoid
flushing the method cache mentioned above by Dan on every increment
GC event. As part of doing this work I studied how the method cache
was working and at least for my ad-hoc test it was getting a 96.4%
hit ratio and as Dan mention the easy selective removal made it easy
to invalidate the entries in the cache based on information at the
point of the incremental GC event.
For the curious I found that 1356 incremental GC events only caused
856 cache entries to be invalidated, versus the flushing the entire
512 entry cache 1356 times.
--
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
More information about the Squeak-dev
mailing list
|