[PATCH] resource: Micro-tune resource hash computation

[Jamey Sharp]

If Hash is performance critical, is there a strong reason not to
replace it with this?

return id & (clientTable[client].buckets - 1);

I'd be interested to see evidence justifying mixing higher-order bits
into the hash.

If the current hash is necessary, is there a typo in the 128 bucket
case? That should be 14, not 13, right? Otherwise the same bit is
getting mixed in twice.

Jamey

On 1/10/11, Adam Jackson <ajax at redhat.com> wrote:
> We do actually call Hash() on resource lookup, so let's not make it more
> expensive than necessary.  The compiler isnmay not be smart enough to
> notice that we only ever have a power of two count of buckets, so
> flatten the log2 math so it doesn't have to know.
>
> Signed-off-by: Adam Jackson <ajax at redhat.com>
> ---
>  dix/resource.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/dix/resource.c b/dix/resource.c
> index 9cdddba..d2cf0e4 100644
> --- a/dix/resource.c
> +++ b/dix/resource.c
> @@ -343,19 +343,19 @@ static int
>  Hash(int client, XID id)
>  {
>      id &= RESOURCE_ID_MASK;
> -    switch (ilog2(clientTable[client].buckets))
> +    switch (clientTable[client].buckets)
>      {
> -	case 6:
> +	case 64:
>  	    return ((int)(0x03F & (id ^ (id>>6) ^ (id>>12))));
> -	case 7:
> +	case 128:
>  	    return ((int)(0x07F & (id ^ (id>>7) ^ (id>>13))));
> -	case 8:
> +	case 256:
>  	    return ((int)(0x0FF & (id ^ (id>>8) ^ (id>>16))));
> -	case 9:
> +	case 512:
>  	    return ((int)(0x1FF & (id ^ (id>>9))));
> -	case 10:
> +	case 1024:
>  	    return ((int)(0x3FF & (id ^ (id>>10))));
> -	case 11:
> +	case 2048:
>  	    return ((int)(0x7FF & (id ^ (id>>11))));
>      }
>      return -1;
> --
> 1.7.3.4
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>