[
https://issues.apache.org/jira/browse/AVRO-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061285#comment-13061285
]
Douglas Kaminsky commented on AVRO-853:
---------------------------------------
FYI, I purposely chose 0 instead of null for thread safety purposes, since
primitives have different characteristics than objects in multithreaded
context. I'm not certain MIN_INT would be any less likely to be chosen than 0
as a hash in general, but if the Avro classes hash to generally positive
numbers, picking any negative number as the "unset" value would be an
improvement.
As pointed out earlier, the worst case is that the "unset" value gets
calculated over and over again and loses the benefit of cache
> Cache hash codes in Schema and Field
> ------------------------------------
>
> Key: AVRO-853
> URL: https://issues.apache.org/jira/browse/AVRO-853
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.5.1
> Reporter: Douglas Kaminsky
> Attachments: AVRO-853-approach2.patch, AVRO-853.patch
>
>
> We are experiencing a serious performance degradation when trying to
> store/retrieve fields and schemas in hash-based data structures (eg.
> HashMap). Since all fields and schemas are immutable (with the exception of
> RecordSchema allowing deferred setting of Fields) it makes sense to cache the
> hash code on the object instead of recalculating every time the hashCode
> method gets called.
> (Are there other mutable Schema sub-types that I'm not thinking about?)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
