Why might a System.String object not cache its hash code?

Obvious potential answer: because that will cost memory.

There’s a cost/benefit analysis here:

Cost: 4 bytes for every string (and a quick test on each call to GetHashCode). Also make the string object mutable, which would obviously mean you’d need to be careful about the
implementation – unless you always compute the hash code up-front, which is a cost of computing it once for every string, regardless of whether you ever hash it at all.

Benefit: Avoid recomputing the hash for string values hashed more than once

I would suggest that in many cases, there are many, many string objects and very few of them are hashed more than once – leading to a net cost. For some cases, obviously that won’t be the case.

I don’t think I’m in a good position to judge which comes up more often… I would hope that MS has instrumented various real apps. (I’d also hope that Sun did the same for Java, which does cache the hash…)

EDIT: I’ve just spoken to Eric Lippert about this (NDC is awesome 🙂 and basically it is about the extra memory hit vs the limited benefits.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)