Re^5: elsif chain vs. dispatch

Replies are listed 'Best First'.
Re^6: elsif chain vs. dispatch by Marshall (Canon) on Apr 27, 2009 at 21:02 UTC
If you let Perl grow the hash, this super degenerate case will be detected and Perl will add bits to the hash key. The num keys start at 8, then 16,32,64,etc. The 9th entry to same hash value with buckets =8 would re-gen the entire hash. Now, I suppose that some case can be generated where at each bit addition, the same thing not only occurs, but becomes harder for earlier versions of Perl to detect! I think my general advice about checking these parms: #buckets used, #total buckets and #total entries is a good one when dealing with very large or performance sensitive hashes.	[reply]
Re^7: elsif chain vs. dispatch by ikegami (Patriarch) on Apr 27, 2009 at 21:16 UTC
The 9th entry to same hash value with buckets =8 would re-gen the entire hash. That doesn't prevent the degenerate case since you could end up with 9 entries in the same bucket of a 16 bucket hash after the split.	[reply]
Re^7: elsif chain vs. dispatch by JavaFan (Canon) on Apr 27, 2009 at 22:40 UTC
But that would mean having N/4 keys hashing to the same bucket isn't detected. Which means the worst case is still `Θ(N)`. In fact, if there's an `ε > 0` such that it requires more than `εN` keys to be hashed to a single bucket before Perl reorders the hash, the worst case look up is still `Θ(N)`.	[reply]
Re^8: elsif chain vs. dispatch by Marshall (Canon) on Apr 27, 2009 at 23:30 UTC
Yes, if I understand your point correctly: There is no absolute guarantee that all keys won't hash to the same hash key until the keys are absolutely unique! Correct! However in a practical sense, I think that you are going to be hard pressed to come up with a realistic example for this user's input data. Of course there is a "trick" here. Even if the hash table has to compare say 16 things to get a result, it is still going to be very fast! This idea that say 256 things will hash into an identical hash table entry is unlikely. Now "very, very seldom" doesn't mean "never". But, as the hash grows the probability of this decreases exponentially.	[reply]
Re^9: elsif chain vs. dispatch by ikegami (Patriarch) on Apr 27, 2009 at 23:36 UTC
Re^10: elsif chain vs. dispatch by Marshall (Canon) on Apr 28, 2009 at 00:02 UTC
Some notes below your chosen depth have not been shown here
Re^9: elsif chain vs. dispatch by JavaFan (Canon) on Apr 28, 2009 at 00:14 UTC
Re^10: elsif chain vs. dispatch by Marshall (Canon) on Apr 28, 2009 at 04:49 UTC
Re^6: elsif chain vs. dispatch by Marshall (Canon) on Apr 27, 2009 at 21:54 UTC
Completely correct! Yes this could happen. If it keeps happening, then the 17th entry would cause the hash to be re-sized. Then again on the 33rd entry. It sounds like Perl 5.8.3+ has made some improvements! Great! For Perl versions less than that and even on Perl 5.8.3, I don't think that a user will know more than #buckets, #buckets used and #total entries (ie, user wouldn't know the max entries into a "bucket"), but given those 3 things, a user can make some judgment call about increasing the hash table size and is able to do so.	[reply]