Ross Boylan wrote:
>>least that method. Of course you should study the matter and take the 
>>appropriate precautions, and test that it really solves your problem, 
>>but strictly at the information level, don't forget to rehash very 
>>quickly after any change in the hashing scheme of any affected data 
>>structures.
> Should the two methods be sufficient to change?  
I can't look into your case specifically enough to answer that. I'm just 
giving you a few pointers so you can shoot yourself in the foot fewer 
times, more quickly. Sorry :-)

But a protocol browser might be helpful. 3.9a has a #scanForNil: that 
should probably match.

> This looks like a 
> hazardous operation.  I have a process which tickles the image every
> few seconds and cause updates which would use some of these
> dictionaries.  I'll suspend that process, but the operation looks very
> thread-unsafe.
#valueUnpreemptively might be helpful.

Also, you can change the methods so that they work with dictionaries 
with new and old type hashes. To do this, search using the new start, if 
you fail, before returning, search again using the old start.

> I'm sure this won't end my performance problems, but I hope it will
> help.
Maybe you need an experiment to determine whether this gives you enough 
improvement to be worth it before you decide if/how to do it safely...

>>Sheesh, amazing how long lived this bug is... if someone has some time 
>>and the inclination to finally put a stake through it, I have some advice.
> I think the bug is dead, so nothing needs to filed about it.  Recall
> that the image with the problem is basically at 3.6 final.  The 3.8
> final has the improved code quoted above.
Actually, many non-identity dictionaries (which therefore do not have 
the arithmetic for start) actually use identityHash (it is the default), 
so I would not consider it dead at all...

Maybe using a chained implementation as is being discussed is the real 
solution.

Daniel