Possible Duplicate:
Why might a System.String object not cache its hash code?
I always thought that, given that .Net strings are immutable, String.GetHashCode() didn’t have to calculate the hash every time it’s called — if the characters won’t change, the hash is constant for a given instance of System.String, I naively thought; String.GetHashCode() could have O(1) complexity.
Reverse engineering it shattered this assumption.
Of course, hash codes aren’t meant to be constant and so on, but what could prevent a String implementation from having hash codes already calculated from, say, construction time?
Good question!
I asked the same thing a while back.
Basically, it’s a speed/memory trade-off. The benefit of caching string hash codes is arguably outweighed by the overhead of every single string object requiring another 32 bits of memory to be allocated. This makes sense when you think about the large number of strings that may exist in a program versus the number whose hash codes you care about (presumably because you’re using them as keys).
The latter number may be large in some programs, but it may also be quite small. It could even be zero in a lot of cases.
If performance were an extreme concern for you in certain scenarios, you might consider writing your own wrapper that does cache its hash code:
To get any benefit out of this, of course, you’d still need to be very careful to reuse these
StringKeyobjects basically throughout your program everywhere. In the vast majority of cases, this would not be worth the effort; I’ve included the idea only as something to consider if you happen to be an exceptional case.