Re: Plan C (was Re: Plan B for fixing 5.8.2 binary API)
Nicholas Clark wrote:
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