diff options
| author | Thomas Schwinge <thomas@schwinge.name> | 2010-07-24 12:51:44 +0200 |
|---|---|---|
| committer | Thomas Schwinge <thomas@schwinge.name> | 2010-07-24 12:51:44 +0200 |
| commit | 883d6915a37f0266479c9b25d8c911ce1e66d315 (patch) | |
| tree | 26fe1f2422c3b3e0e7d7274c596c5374c647bcac | |
| parent | 6dc393369a96f1629dea8fe4687a4c2e36502b89 (diff) | |
hurd/libihash: IRC discussion.
| -rw-r--r-- | hurd/libihash.mdwn | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn index 58b6368c..39692939 100644 --- a/hurd/libihash.mdwn +++ b/hurd/libihash.mdwn @@ -8,6 +8,20 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] + * IRC, unknown channel, unknown date + + [[!tag open_issue_hurd]] + + <neal> so, we need a new ihash implementation + <neal> marcusb: When 80% full, the collision rate is very high. + <neal> marcusb: I tested using 512mb / 4096 entries + <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster. + <marcusb> yeah, it shouldn't get so full + <marcusb> don't we do an exponential back-off in the array size? + <marcusb> of course it's clear we can do much better + <marcusb> the ihash algo is very simple + <marcusb> I'm not even sure it makes much sense to have a generic library + * Hurd libihash * old @@ -33,3 +47,5 @@ is included in the section entitled * <http://cmph.sourceforge.net/> * <http://libhashish.sourceforge.net/> + + * <http://www.azillionmonkeys.com/qed/hash.html> |