CODEWITHSUNDEEP
javahashcode
Glains
Glains

Reputation: 2863

Precompute hashCode for value-based classes?

Value-based classes have the property that they

are final and immutable (though may contain references to mutable objects).

Consequently, if you know that your object only contains immutable instances, you could precompute the hashCode of the instance. This could speed up access when using Map or Set operations.

Looking at the implementation of hashCode from Instant, which is a value-based class, why have the developers decided against this pattern? Would the loss of performance for precomputing the hashCode be more significant than computing it over and over again when required?

// copied from Instant#hashCode
@Override
public int hashCode() {
    return ((int) (seconds ^ (seconds >>> 32))) + 51 * nanos;
}

So, under what condition is precomputing the hashCode justified?

Upvotes: 6

Views: 401

Answers (1)

Jatin
Jatin

Reputation: 31744

There isn't straight-forward reason why Instant doesn't cache hashcode. But some that I could think of:

Caching hashcode comes at a price: the instance variable declared:

  • It of-course occupies more memory per object. It may be alright to re-compute the hashcode, than allocate extra memory for every instance object
  • Worry about serialization/deserialization, as the instance variable would need to be preserved. Increasing the size of the serialized object
  • The internal implementation becomes difficult to be modified in future versions. Especially more so because of past serialized objects. Preserving backward compatibility becomes difficult for past version objects. Extra maintenance.
  • hashcode may never be called on an Instant object. In such a case, we waste CPU in computing something that is never used

So may not make sense to cache. May be it makes sense for String as it is so commonly used throughout. May be worth the headache.

Upvotes: 4

Related Questions