Some experiments with the XCodecHash suggest that it doesn't benefit from doing an xor of bytes in the hashed data and that it costs a non-trivial amount of performance.  If nothing else, we store two copies of the byte being rolled in, which is unacceptable.  In the future, just Jenkins mixing the low 32-bits and using the upper 32-bits for UUID is probably workable.  Actually, maybe we'd be best off just using 32-bit hashes.  Dunno.  Depends how we store hashes sent by the peer and whether we generate references to them, etc.?
Some experiments with the XCodecHash suggest that it doesn't benefit from doing
an xor of bytes in the hashed data and that it costs a non-trivial amount of
performance.  If nothing else, we store two copies of the byte being rolled in,
which is unacceptable.  In the future, just Jenkins mixing the low 32-bits and
using the upper 32-bits for UUID is probably workable.  Actually, maybe we'd be
best off just using 32-bit hashes.  Dunno.  Depends how we store hashes sent by
the peer and whether we generate references to them, etc.?


git-svn-id: 9e2532540f1574e817ce42f20b9d0fb64899e451@262 4068ffdb-0463-0410-8185-8cc71e3bd399

splbio/wanproxy,splbio/wanproxy,diegows/wanproxy,diegows/wanproxy,splbio/wanproxy,diegows/wanproxy