Can I depend on the values of GetHashCode() to be consistent?

Question

Is the return value of GetHashCode() guaranteed to be consistent assuming the same string value is being used? (C#/ASP.NET)

I uploaded my code to a server today and to my surprise I had to reindex some data because my server (win2008 64-bit) was returning different values compared to my desktop computer.

Phellem

Answer 1

If I'm not mistaken, GetHashCode is consistent given the same value, but it is NOT guaranteed to be consistent across different versions of the framework.

From the MSDN docs on String.GetHashCode():

The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode.

Streak

Conclusion: Never persist or transmit the result of GetHashCode(). Use it only for its intended purpose: to facilitate the use of hash tables. – Disaccord

Answer 2

I had a similar problem where I filled a database table with information which was dependent on String.GetHashCode (Not the best idea) and when I upgraded the server I was working on to x64 I noticed the values I was getting from String.GetHashCode were inconsistent with what was already in the table. My solution was to use my own version of GetHashCode which returns the same value as String.GetHashCode on a x86 framework.

Here's the code, don't forget to compile with "Allow unsafe code":

    /// <summary>
    /// Similar to String.GetHashCode but returns the same as the x86 version of String.GetHashCode for x64 and x86 frameworks.
    /// </summary>
    /// <param name="s"></param>
    /// <returns></returns>
    public static unsafe int GetHashCode32(string s)
    {
        fixed (char* str = s.ToCharArray())
        {
            char* chPtr = str;
            int num = 0x15051505;
            int num2 = num;
            int* numPtr = (int*)chPtr;
            for (int i = s.Length; i > 0; i -= 4)
            {
                num = (((num << 5) + num) + (num >> 0x1b)) ^ numPtr[0];
                if (i <= 2)
                {
                    break;
                }
                num2 = (((num2 << 5) + num2) + (num2 >> 0x1b)) ^ numPtr[1];
                numPtr += 2;
            }
            return (num + (num2 * 0x5d588b65));
        }
    }

Splashboard

I had the same problem and ported your version to a safe method. gist.github.com/gerriten/7542231#file-gethashcode32-net – Dud

Answer 3

The implementation is dependent on the version of the framework but it also depends on the architecture. The implementation of string.GetHashCode() is dfferent in the x86 and x64 versions of the framework even if they have the same version number.

Cephalic

Answer 4

I wonder if there are differences between 32-bit and 64-bit operating systems, because I am certain both my server and home computer are running the same version of .NET

I was always weary of using GetHashCode(), it might be a good idea for me to simply role my own hash algorithm. Well at least I ended up writing a quick re-index .aspx page because of it.

Phellem

Answer 5

Are you running Win2008 x86 as your desktop? Because Win2008 includes version 2.0.50727.1434, which is an updated version of 2.0 included in Vista RTM.

Chauncey

Answer 6

Not a direct answer to your question, which Jonas has answered well, however this may be of assistance if you are worried about equality testing in hashes

From our tests, depending on what you are requiring with hashcodes, in C#, hashcodes do not need to be unique for Equality operations. As an example, consider the following:

We had a requirement to overload the equals operator, and therefore the GetHashCode function of our objects as they had become volatile and stateless, and sourcing themselves directly from data, so in one place of the application we needed to ensure that an object would be viewed as equal to another object if it was sourced from the same data, not just if it was the same reference. Our unique data identifiers are Guids.

The equals operator was easy to cater for as we just checked on the Guid of the record (after checking for null).

Unfortuantely the HashCode data size (being an int) depends on the operating system, and on our 32 bit system, the hashcode would be 32 bit. Mathematically, when we override the GetHashCode function, it is impossible to generate a unique hashcode from a guid which is greater than 32 bit (look at it from the converse, how would you translate a 32 bit integer into a guid?).

We then did some tests where we took the Guid as a string and returned the HashCode of the Guid, which almost always returns a unique identifier in our tests, but not always.

What we did notice however, when an object is in a hashed collection object (a hashtable, a dictionary etc), when 2 objects are not unique but their hashcodes are, the hashcode is only used as a first option lookup, if there are non-unique hash codes being used, the equality operator is always used as a fall back to detirmine equality.

As I said this may or may not be relevant to your situation, but if it is it's a handy tip.

UPDATE

To demonstrate, we have a Hashtable:

Key:Object A (Hashcode 1), value Object A1

Key:Object B (Hashcode 1), value Object B1

Key:Object C (Hashcode 1), value Object C1

Key:Object D (Hashcode 2), value Object D1

Key:Object E (Hashcode 3), value Object E1

When I call the hashtable for the object with the key of Object A, the object A1 will be returned after 2 steps, a call for hashcode 1, then an equality check on the key object as there is not a unique key with the hashcode 1

When I call the hashtable for the object with the key of Object D, the object D1 will be returned after 1 step, a hash lookup

Ineradicable

Answer 7

What we did notice however, when an object is in a hashed collection object (a hashtable, a dictionary etc), when 2 objects are not unique but their hashcodes are, the hashcode is only used as a first option lookup, if there are non-unique hash codes being used, the equality operator is always used as a fall back to detirmine equality.

This is the way hash lookups work, right? Each bucket contains a list of items having the same hash code.

So to find the correct item under these conditions a linear search using value equality comparison takes place.

And if your hashing implementation achieves good distribution, this search is not required, i.e., one item per bucket.

Is my understanding correct?

Understandable

Ben, from our test, this is true. The second equality search only runs as required. You can test it yourself by overloading the ==, !=, Equals() and GetHashCode of a certain object. I found it very interesting (but I am a geek :) ) – Ineradicable

(continued), so the knock on effect of nonunique hash codes would be slower performance to run the equality check, but in our situation where the nonunique value is very rare, it is largely insignificant – Ineradicable

Answer 8

    /// <summary>
    /// Default implementation of string.GetHashCode is not consistent on different platforms (x32/x64 which is our case) and frameworks. 
    /// FNV-1a - (Fowler/Noll/Vo) is a fast, consistent, non-cryptographic hash algorithm with good dispersion. (see http://isthe.com/chongo/tech/comp/fnv/#FNV-1a)
    /// </summary>
    private static int GetFNV1aHashCode(string str)
    {
        if (str == null)
            return 0;
        var length = str.Length;
        // original FNV-1a has 32 bit offset_basis = 2166136261 but length gives a bit better dispersion (2%) for our case where all the strings are equal length, for example: "3EC0FFFF01ECD9C4001B01E2A707"
        int hash = length;
        for (int i = 0; i != length; ++i)
            hash = (hash ^ str[i]) * 16777619;
        return hash;
    }

This implementation can be slower than the unsafe one posted before. But much simpler and safe.

Saiva

This is FNV1a, a completely different algorithm to what is used in GetHashCode, which is not what OP is asking about. – Devora

It is different, but it's a easy, helpful solution to the problem the OP is experiencing +1 – Proton

Answer 9

I would have to Say...you cannot rely on it. For example if I run file1 through c#'s md5 hash code and copy nd paste the same file to a new directory...the hash code come out different even tough it is he same file. Obviously its the same .net version, same everything. The only thing that changed was the path.

Boride