eclipse
Create immutable primitive collection wrappers which cache the hashcode.
For immutable primitive collections, it makes sense to cache the hash code once it is calculated. Currently, it is recalculated everytime.
A similar strategy to the one in java.lang.String#hashCode can be used.
Thanks for the interesting proposal! Your suggestion makes sense to me.
Would you be interested in contributing to this issue? We are happy to accept contributions. Please let us know.
It's not always advantageous to cache the hash code. Consider an immutable singleton set containing a String. Caching the hash code would increase memory usage and not have a material impact on speed since the String already caches the hash code. And the speed of a collection's hash code calculation only matters if it's stored in another hash table. How common is that?
An alternative would be to add wrappers that cache the hash code. The wrapper would implement an immutable interface like ImmutableSet, delegate all methods except hashCode, and cache the hash code.
@motlin , my understanding is that this proposal is only for immutable "primitive" collections, so strictly speaking, your counter argument might not be relevant.
Though you made the valid point that adding cache increase memory consumption, especially for fixed size collections. Also it might not be too common to care about the hash speed for collections.
The suggestion to add wrappers helps users to choose better hash speed containers only when they need, so I agree with that approach if we were to implement this.
Adding a wrapper gives clients the flexibility to choose to have the overhead of maintaining a cached hash code (however, minimal). I agree.
@itohro I'll pick this up and raise a pull request in the coming week.
@motlin The actual use case was to use a byte array as a key, and avoid the retrofitting of ByteBuffer. But you're right. It is not really a common use case.
@vijay-daniel Are you still interested in contributing this or should I close the issue?
