Yves/remove stadtx #18569
Yves/remove stadtx #18569
Conversation
git ls-files returns the list of currently staged files. If a patch is aimed at removing a file, thus deleting it and removing it from MANIFEST but the dev has not staged the changes we should not say it fails test.
For sake of posterity, can you please actually explain here why this is necessary. |
|
I wrote Stadtx to be fast, but i overlooked some real statistical issues in how it works. For certain keys it will be far less well distributed than preferable. meaning more bucket splits than necessary, more linked list searches than necessary, and less efficient utilization of available memory. The perl hash data structure degrades relatively well under these conditions, but the tiny speedup of the actual string hashing compared to the other costs isn't worth it. Having less collisions per bucket mitigates the speed differences to a certain extent also. Siphash produces well distributed data, hashes reasonably fast (especially in the 1-3 variant) and is one of the few widely used and peer reviewed PRF's. Stadtx is a project i came up with to see if I could create a fast hash function. There isn't even a question in terms of statistical quality comparison. If we want to provide a "fast" hash then someone else can select one from the herd, but Stadtx shouldnt be an option. |
|
Also I should mention that Stephen Dolan did some quality research into this. I had actually discovered the same issues independently but he did a much more formal investigation. Credit goes to him for instigating this removal. |
|
You've gone from a pull request to removal of a documented feature in
two hours and forty-two minutes.
Can you explain why this should not have been put through a deprecation
cycle?
Or why it was rushed through so quickly?
Thank you very much.
Jim Keenan
|
Yes, this. Don't get me wrong, I think this removal is the right decision, but you should at least give the rest of us a chance to come to that conclusion before merging it. |
Nuff said.