Benefit from computing String Hash at compile time?

[Mark Thornton]

Osvaldo Pinali Doederlein wrote:
> attached in the end) - to no avail. I believe one significant problem is 
> that the hashing function is not friendly to optimization; something 
> like str[0] ^ str[1] ^ str[2]... would be much better (i.e., any 
> function that allows loop unrolling and SIMD tricks). But, as we've 
> already discussed, String.hashCode()'s algorithm cannot be changed so 
> it's pointless considering this.
>   

from JavaDoc: s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

= s[0]*31^(n-1) + s[2]*31^(n-3) + ... +
  s[1]*31^(n-2) + s[4]*31^(n-4) + ...


int hOdd = 0;
int hEven = 0;
final int mSquared = 31*31;

int ne = s.length() &~1;
for (int i=0; i<ne; i+=2) {
   hEven = mSquared*hEven+s.charAt(i);
   hOdd = mSquared*hOdd+s.charAt(i+1);
}
if (ne < s.length() {
   hEven = mSquared*hEven+s.charAt(ne);
   return hEven+31*hOdd;
}
else {
   return 31*hEven+hOdd;
}

Other variations possible. For really long Strings, divide the string into 
M pieces where M is the number of processors available.

Mark Thornton