Re: String hashCode

[Per Bothner <per at bothner dot com>]

Bryce McKinlay <bryce@albatross.co.nz> writes:

> Is there a reason not to keep a hashcode field in String objects,
> instead of recalculating it every time String.hashCode() is called?

There are always reasons:

(1) Keeping the hashCode in the String uses an extra 32 bits per String.

(2) Then there is the question of whether you calculate the hashCode
when you create the String (may waste time if the hashCode is never used)
or the first time hashCode is called (need an indication of whether the
hashCode is valid, and need to test the indication).

(3) If the hashCode is calculated when the String is created, then
substring changes from an O(1) operation to an O(N) operation,
where N is the length of the new substring.

> This would speed up String.equals() by being able to return false
> quickly in the common case, as well as speeding up things like
> Hashtables of Strings and string interning.

Yup.

Its a reasonable thing to do - but there are some costs.

It might also be useful to have a way to quickly determine if a
String is interned.  This could be done by determining that
this.data==data and boffset has a magic value - perhaps
just enough to leave room for a hashCode before the String proper.

At the least it makes sense to maintain the hashCode for interned
Strings.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/