Re: g_str_hash
- From: Tim Janik <timj gtk org>
- To: gtk-devel-list redhat com
- Subject: Re: g_str_hash
- Date: Fri, 11 Feb 2000 16:18:15 +0100 (CET)
On 11 Feb 2000, Owen Taylor wrote:
> Tim Janik <timj@gtk.org> writes:
> > guint
> > g_str_hash (gconstpointer string)
> > {
> > register const gchar *p = string;
> > register guint h = *p;
> >
> > for (p = string + 1; *p; p++)
> > h += (h << 4) + *p;
> >
> > return h;
> > }
> >
> > and for high-bit feedback:
> I'm not sure this is a good idea: one point of glib is that people can
> use it without having to understand things to the level of detail
> of having to understand tradeoffs between different hash functions.
that's merely a matter of documenting the intended use of the hash functions,
e.g. we recommend using g_str_hash_long() if the average string of your
hash table is longer than >=10 characters and tends to have a higher
distribution in the string head than the tail.
> The perl version effectively uses '<< 5' instead of '<< 4',
> and also differs by having
thanks for catching that, g_str_hash() should have read h += (h << 5) + *p;
> return (h >> 5) + h;
>
> instead of 'return h'; something I don't completely understand.
hm, odd indeed, unless they use powers of 2 instead of prime numbers
for their hash table sizes ;) i don't really see how that would make
a difference.
> It would take a bit of experimentation to see how the Tcl/Perl
> versions perform on long strings that differ only in their tail, but I
> suspect that
>
> a) Inserting such strings into a hash table is rare (and
> slow anyways)
well that depends on what you mean with "such" (long) strings,
the ASU version starts feedback after the 7th character.
> b) They'll probably do OK anyways
>
> Regards,
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]