- snip -
it first checks if the hash of any element begins with the same first three characters as the hash we're searching for.
- snip -
While I see a few things about this technique that are ignored and not included in the "findings", and I believe significantly better search algorithms already exist, I'm most curious why you chose
THREE, specifically, as the number of "characters" to check? Is there something about
THREE that makes it better than
TWO or
FOUR (or any other number)? Have you tried your simulations with other prefix sizes to find the optimal prefix size?
Also, it seems very inefficient to take a hash (which is a large binary number), and first convert it to a string representation of its value as represented in hexadecimal, and then use string manipulation to compare "characters"? Wouldn't it be much faster and simpler to perform a bitwise XOR
onbetween some predetermined prefix of bits of the hash
itself (or evencomputed from the list element and the same prefix of bits on the
entiretarget hash
itself).
And, if you ARE going to use XOR, is there a benefit to taking the extra steps to generate a bitwise prefix since XOR is so incredibly fast as a comparison method?
In the time you spend separating the prefix from the initial hash, the XOR between the full hash values would likely already have completed, wouldn't it?