Liste des Groupes | Revenir à cl c |
bart <bc@freeuk.com> writes:
It looks like your hash function was tuned for this testingIt wasn't tuned at all; it was a copy of what I've longed used within my lexers.
setup. With different choices for testing it does much
worse.
The testing is done with malloc() blocks all of the same
requested size, and that size is 1. Typical workloads
are likely to be both larger and more variable.
When adding a new entry finds a collision with an oldYou mean Malcolm's version? That also uses a loop. Neither need to process all 8 bytes of a 64-bit pointer; 6 will do, and probably just 4.
entry, linear probing is used to find a free slot. It's
well understood that linear probing suffers badly as the
load factor goes up. Better to take a few high bits of
the hash value -- as few as five or six is fine -- to
have the reprobe sequences have different strides.
Your hash function is expensive to compute, moreso even
than the "FNV" function shown earlier.
this one where the compares are cheap, it's better toMy first thought in this thread was to just make use of the pointer value directly. My version was written only to compare against Malcolm's FNV code.
have a dumb-but-fast hash function that might need a
few more looks to find an open slot, because the cost
of looking is so cheap compared to computing the hash
function.
Les messages affichés proviennent d'usenet.