Re: HashMap vs linear table lookup

Peter Duniho wrote:
On Thu, 21 Feb 2008 14:59:28 -0800, EJP
<esmond.not.pitt@xxxxxxxxxxxxxxx> wrote:

Lew wrote:
Are you sure of that?

Yes.

P.S., please attribute your citations.

The source code.

Or do you think I just make this stuff up?

Well, to be fair: there is in fact a difference between a general
statement such as yours ("the hashCode for a String is computed once
per String") and a qualified statement such as the one Thomas offers
("the sun implementation caches the hash").

Looking at the source code for the Sun implementation doesn't tell
you
what all implementations do, and unless the Java specification
specifically says that all implementations must cache the hash code,
there's no guarantee that they do.

You seem offended by Lew's question, but I think it's a reasonable
one. Is there in fact a genuine guarantee that every implementation
of String will always cache the hash code? Or is this an
implementation-dependent behavior?

Granted, the answer may be academic. It's not like one has much, if
any, control over the behavior and I don't think it's the sort of
thing that should, all else being equal, cause someone to dismiss a
HashMap as a solution.

But we're all programmers here, and as such we often have a need for
being very specific and literal in our understanding of what's being
said. Unless you have some reason to believe that _all_ Java
implementations are _guaranteed_ to cache the hash code, a statement
about what the actual behavior of String is should IMHO be qualified
as Thomas's was, if for no other reason than to offer enhanced
clarity regarding what you're actually saying.


I agree 100% with the points you're making. Anything not guaranteed
by the documentation is implementation-specific, and cannot be relied
on.

In this case, though, I'll qualifiy that: the main implementation, on
which all others not developed in a clean room are based, has AFAIK
always cached the hash code. Moreover, doing so is almost free, and
there are no disadvantages beyond the extra two allocated bytes. (I'm
not such an expert in JVM implementation that I know what the actual
cost in space is: it may be zero, or it may be as much as N bytes
where all objects are allocated on N-byte boundaries.) So I'm
willing, *in this case*, to act as if that all implementations do it
until I'm shown one that doesn't.


.

Relevant Pages

  • Re: how to generate unique Hash Code for string
    ... same string always, and generate different-2 Hash Code Different-2 ... MSDN can't guarantee this, because it is not possible to give such a ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: HashMap vs linear table lookup
    ... statement such as yours ("the hashCode for a String is computed once per String") and a qualified statement such as the one Thomas offers. ... Looking at the source code for the Sun implementation doesn't tell you what all implementations do, and unless the Java specification specifically says that all implementations must cache the hash code, there's no guarantee that they do. ... Unless you have some reason to believe that _all_ Java implementations are _guaranteed_ to cache the hash code, a statement about what the actual behavior of String is should IMHO be qualified as Thomas's was, if for no other reason than to offer enhanced clarity regarding what you're actually saying. ...
    (comp.lang.java.programmer)
  • Re: PLS HELP: HUGE problem with Hashcode
    ... There is no guarantee that the hash code generated by GetHashcode will be the same across different invocations of the same app at different times. ... the implementation of GetHashCode provided by the String class returns unique hash codes for unique string values. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: WaitForSingleObject() will not deadlock
    ... But what is TSO? ... Technical Standard Order, a minimum performance standard issued by the FAA for certain ... have been more commonly referred to as the "cache coherency" ... A mutex is sufficient to guarantee visibility, ...
    (microsoft.public.vc.mfc)
  • Re: 32-bit programs on Windows x64
    ... THE AMOUNT OF RAM ON THE MACHINE IS COMPLETELY, ... on thinking about physical memory as being an operational ... to compare its input string against every possible valid ... Note that the L2 cache is ...
    (microsoft.public.vc.mfc)