Re: hash codes
Simon wrote:
Patricia Shanahan wrote:
You seem to be ignoring the issue of which class caches hash codes when.
String does not cache hash codes.
From the source of String.java, JDK 1.6.0
/** Cache the hash code for the string */
private int hash; // Default to 0
[...]
Sorry about that, I did check and found it does cache when hashCode is
called, but forgot I had already typed that line.
It is possible that it might be a gain, but not obvious. It would
require experiments across a wide range of benchmarks.
ACK.
Well. One could use at least the first option since this one is
essentially free.
Nope. If it does any good at all, it costs three comparisons.
You wrote in an earlier post:
HashMap needs the hash code anyway, so pre-checking is effectively free.
I'm just saying: If String.equals() does have the hash code anyway (by chance),
pre-checking is effectively free. Three comparisons aren't all that much are
they? You need 2 comparisons in any iteration of the comparison loop.
There are two important differences between HashMap and String on this:
1. HashMap must calculate the hash code in order to find the right
bucket, so it never has to test whether the hash code has been
calculated. It only has to do one compare, not three, to know that two
strings have different hash codes. String may nor may not already have
one or both hash codes, so it has to test whether they exist.
2. HashMap is going to have to incur the cost of a method call, at an
absolute minimum, if it does call equals. String is already sitting in
its own equals method, all ready to start comparing characters.
A lot depends on both the probability of an equals call for two String
instances that have different hash codes and both have been calculated,
and the average number of iterations of the comparison loop, given the
strings are different.
Patricia