On Sat, Mar 01, 2003 at 10:03:47PM +0900, ts wrote:
> >>>>> "M" == Mauricio =?iso-8859-1?Q?Fern=E1ndez?= <Mauricio> writes:
> 
> M> The strange thing is that, even though the new hash function was not
> M> being used (and BTW, it turned out it's not Jenkins but "one-at-a-time"),
> M> I got some speed increase in simple benchmarks. I believe it's because
> M> I got rid of the primes and modulus calculations and replaced it with
> M> bitwise and...
> 
>  Yes, I think this is the replacement of '%' by '&' which make it faster
>  (the difference is in st_lookup())
> 
> M> I'm changing string.c and benchmarking again. I will try the
> M> "one-at-a-time" hash and Jenkins (it's possible here as we know the
> M> length of the string) to see what's better. Stay tuned :)
> 
>  Probably wrong but it's slower for me.

You mean you have already changed string.c and now it's slower?
With what function, Jenkins or "one-at-a-time"?

At the end of the day, if we keep the current hash and use & instead of %
and gain up to 30% speed in array access (that's the result of another
simple test of the GCLS) it will have been worth the effort.

-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Let's call it an accidental feature.
	--Larry Wall