HashMap put performance

Question

I have been getting confused about some yourkit snapshots which seems to suggest that in a particular stack hashmap.put() is proving to be costly.

Let's say the key for this map is a very complex object which has not overridden equals() or hashCode()

Is it really possible for HashMap.hash() or Object.hashCode() to be costly in certain situations ?

Answer 1

It certainly is possible to create an object which is costly to put into a HashMap:

class Awful {
    @Override
    public int hashCode() {
        try {
            Thread.sleep(10000000);
        } catch (InterruptedException e) {
           Thread.currentThread().interrupt();
        }
        return 1;
    }
}

Obviously this is a contrived example but I've seen implementations that call methods on Hibernate backed, lazy loaded objects. Putting said object into a list resulted in numerous, quite expensive, database lookups.

Without overriding hashCode() the value is derived from the address of the object, which the JVM already has at the point the method is called, so it's (as good as) instant.

Answer 2

It is theoretically possible, but highly unlikely.

If you are really using Object.hashcode() then that delegates to System.identityHashCode(Object) which is relatively cheap. Furthermore, identity hashcodes should not give you collision hotspots ... unless you get really unlucky.

If you are seeing a performance hotspot, in HashMap.hash() and Object.hashCode(), then perhaps the reason is that you are just doing lots of HashMap lookups.

Answer 3

You said your profiler indicated put as the hot spot, not the hashcode calculation. put is about much more than just hashcode determination. Particularly, if the map is very large, there will be a lot of housekeeping work done. And if your code does little else but invoke put a huge number of times, then naturally this will show up in the profiler as the hot spot. There may be nothing wrong with its performance, though.

Answer 4

I believe yourkit can't always be trusted. Under heavy JIT optimizations profilers they get confused and starts showing up costs at awkward positions.