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