75% of the hash fetch/store API allows the caller to pass in a pre-computed hash value. I'm not aware of how many things use this, but I know that the peephole optimiser changes most string constants that are to be used for hash lookups into SVs that contain the pre-computed hash value. I think that Nick I-S reported that the change that this was part of accelerated one of his real-world TK apps by about 2%, so it seems that in some cases there are speed gains to be had from pre-computed hashing.
If we always used the second strategy, then we throw away these pre-computed hash values (if they are passed in). We'll actually be penalising these callers, rather than optimising. All this for defence against an uncommon case (an algorithmic attack (or pathological data))
Ah thanks, I understand now. However, to me at least, the more byzantine the proposed solutions get, the more attractive breaking binary compatibility seems...
-- Alan Burlison --
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
