[
https://issues.apache.org/jira/browse/AVRO-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189629#comment-15189629
]
Doug Cutting commented on AVRO-1809:
------------------------------------
Can you please benchmark this change, ideally including its impact on
multithreaded performance?
Generally, each past performance optimization was only made only after
demonstrating measurable improvement. For single-threaded performance, this is
usually with Perf.java. There aren't yet standard benchmarks for
multi-threaded performance.
The changes that led to the current implementation are primarily discussed in
the following issues:
https://issues.apache.org/jira/browse/AVRO-743
https://issues.apache.org/jira/browse/AVRO-557
> I wish to remove optimization from GenericDatumReader.getResolver
> -----------------------------------------------------------------
>
> Key: AVRO-1809
> URL: https://issues.apache.org/jira/browse/AVRO-1809
> Project: Avro
> Issue Type: Wish
> Components: java
> Reporter: Konstantin Usachev
> Priority: Minor
>
> There is an optimization at
> org.apache.avro.generic.GenericDatumReader.getResolver, when we cache creator
> thread and it's first returned value. At first, It looks redundant, because
> it saves three calls to Map.get, which is unmeasurable, especially after
> Schema's hashcode calculation optimization, made by the same author
> [~cutting], it's not obvious and adds additional complexity. Also caching of
> current thread whould be a source of bugs in case of different green threads
> libraries integration (which, actually, occurred during integration with
> Quasar).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)