On Mon, 03 Nov 2003 10:16:06 +0000, Alan Burlison <Alan.Burlison@sun.com> wrote: >What is your intention for how 5.8.n where 'n' is >= 3 will handle the hash >key binary compatibility issue? At what point will we break backwards >binary compatibility and just have *all* hashing use the seed with no 'Oh >dear I'm under attack, switch behaviour' logic? Obviously there is a >performance hit for this 5.8.0/5.8.1 binary compatibility stuff, and I did >get the impression that at some point we would switch over entirely to the >new mechanism. The overall performance impact of the new hash splitting algorithm seems to be positive. A performance "hit" we want to keep. :) There may be a slight additional cost about switching hash algorithms because precomputed hash values are ignored after the seed changes for that particular hash. Since switching the seed should happen rarely under normal circumstances, I doubt this effect is noticeable in normal applications. Benchmarks welcome... :) >I think it needs to be clearly documented in 5.8.2 somewhere that we will at >some point break binary compatibility, so people can prepare for it. That should be by switching to Perl 5.10 I would say. The maintenance track is about maintaining compatibility. Certainly getting a 0.2% speed improvement (just guessing here) is not a justification for breaking binary compatibility in the maintenance track. >Also, I don't actually care about 5.8.0/5.8.1 binary compatibility, as we >didn't ship either version. I'd therefore like to permenantly enable the >new behaviour so that I don't have to take a potential prrformance hit, and >so I don't have to break binary compatibility in the future. Is there going >to be a Configure flag to allow me to do this? I'm surprised that you are worried about breaking binary compatibility in the future given how cavalier you are about breaking it right now. Is it just because breaking it now doesn't affect yourself? :) Cheers, -JanThread Previous | Thread Next