Re: [PATCH] simple hash table implementation

[Jeff Trawick <tr...@bellsouth.net>]

> Here's some code I wrote this evening (not strictly a patch though). I
> haven't tested it beyond compiling it yet, but you might have some
> useful comments to make. The files are src/lib/apr/include/apr_hash.h
> and src/lib/apr/lib/apr_hash.c.
> 
> Tony.
> -- 
> f.a.n.finch    fanf@demon.net    dot@dotat.at
> 208 it's a wonderful meat

ship it already...  I may need it for something in another couple of
months and if you don't start trying to ship it now it may not be
ready then :)  (The interface looks reasonable to me, though I wouldn't
be shocked if I had some strange desires after getting around to using
it.)

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Re: [PATCH] simple hash table implementation

[Tony Finch <do...@dotat.at>]

Greg Stein <gs...@lyra.org> wrote:
>
>In truth, I'm only +0 on adding custom hash functions (most of the custom
>hashing is really for speed rather than creating a more uniform
>distribution). If/when a need *actually* arises, then we can go back in
>there and add the functions.

That's my conclusion, too: it only involves adding a couple of
functions to the API and a bit of code shuffling.

Tony.
-- 
f.a.n.finch    fanf@demon.net    dot@dotat.at
407 gristle-clog in the ham juicer

Re: [PATCH] simple hash table implementation

[Greg Stein <gs...@lyra.org>]

On Thu, 4 May 2000, Tony Finch wrote:
> Jeff Trawick <tr...@bellsouth.net> wrote:
> >Thanks!  I'm looking forward to using it as the basis for an
> >optional cache of APR character set translation stuff...
> 
> I just remembered that I was going to add an
> 	if (klen == 0)
> 		klen = strlen(key) + 1;
> to find_entry() before committing, and I was thinking about Greg's
> suggestions, hence the delay...

Guess I should respond to the alternate hashing problem then, eh? :-)

If I have explicit information about the domain of my keys, then I can
construct a much better hash than the provided hash. For example, if I
know the keys are 16-bit integers in the range [0,32767], then my input
hash function will be the identity function (faster).

If the keys are pathnames, then I might want to hash on just the last 10
characters, on the assumption that is where the significant differences
are.

In truth, I'm only +0 on adding custom hash functions (most of the custom
hashing is really for speed rather than creating a more uniform
distribution). If/when a need *actually* arises, then we can go back in
there and add the functions.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] simple hash table implementation

[Tony Finch <do...@dotat.at>]

Jeff Trawick <tr...@bellsouth.net> wrote:
>Thanks!  I'm looking forward to using it as the basis for an
>optional cache of APR character set translation stuff...

I just remembered that I was going to add an
	if (klen == 0)
		klen = strlen(key) + 1;
to find_entry() before committing, and I was thinking about Greg's
suggestions, hence the delay...

Tony.
-- 
f.a.n.finch    fanf@demon.net    dot@dotat.at
212 industrial strength comedy remover

Re: [PATCH] simple hash table implementation

[Jeff Trawick <tr...@bellsouth.net>]

Thanks!  I'm looking forward to using it as the basis for an
optional cache of APR character set translation stuff...

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Re: [PATCH] simple hash table implementation

[Tony Finch <do...@dotat.at>]

Jeff Trawick <tr...@bellsouth.net> wrote:
>
>ship it already...

OK :-)

Tony.
-- 
f.a.n.finch    fanf@demon.net    dot@dotat.at
457 honey wagon hayride