Re: hash codes
Simon wrote:
....
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.
....
I should perhaps explain why I think comparisons can be a big deal. The
problem is not the comparison itself, which can be just as fast as an
integer add, but the conditional branch that follows.
One of the nastiest, most disruptive things you can do to a processor is
force it to empty its pipeline and begin again.
The processor has to decide what to load next in the pipeline
immediately after loading the branch, many cycles before it executes and
the processor finds out if it is taken or not taken. The processor has
to guess, and if it guesses wrong all the code in the pipeline following
the branch is junk, and must be thrown away. It will have to wait for
the correct instructions to work their way through before it can do any
more useful work.
To reduce the frequency, processor designs incorporate various attempts
to predict the branch direction for frequently executed branches. Branch
prediction depends on the same sort of issues as caching - essentially,
it is an attempt to predict behavior based on recent history.
However, I don't think the branches involved in testing for hash codes
unequal but both non-zero are going to be particularly predictable, so
there is a good chance that at least one of them will be mispredicted.
Again, this is something that can only really be evaluated by
experiment, but the stakes are far higher than adding a few integer
instructions.
Patricia