Why is String.GetHashCode() implemented differently in 32-bit and 64-bit versions of the CLR?

What are the technical reasons behind the difference between the 32-bit and 64-bit versions of string.GetHashCode()?

More importa开发者_开发技巧ntly, why does the 64-bit version seem to terminate its algorithm when it encounters the NUL character? For example, the following expressions all return true when run under the 64-bit CLR.

"\0123456789".GetHashCode() == "\0987654321".GetHashCode()
"\0AAAAAAAAA".GetHashCode() == "\0BBBBBBBBB".GetHashCode()
"\0The".GetHashCode() == "\0Game".GetHashCode()

This behavior (bug?) manifested as a performance issue when we used such strings as keys in a Dictionary.

This looks like a known issue which Microsoft would not fix:

As you have mentioned this would be a breaking change for some programs (even though they shouldn't really be relying on this), the risk of this was deemed too high to fix this in the current release.

I agree that the rate of collisions that this will cause in the default Dictionary<String, Object> will be inflated by this. If this is adversely effecting your applications performance, I would suggest trying to work around it by using one of the Dictionary constructors that takes an IEqualityComparer so you can provide a more appropriate GetHashCode implementation. I know this isn't ideal and would like to get this fixed in a future version of the .NET Framework.

Source: Microsoft Connect - String.GetHashCode ignores any characters in the string beyond the first null byte in x64 runtime

Eric lippert has got a wondeful blog to this Curious property in String

Curious property Revealed