[
https://issues.apache.org/jira/browse/AVRO-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800799#action_12800799
]
Thiruvalluvan M. G. commented on AVRO-327:
------------------------------------------
bq. More generally, since BinaryDecoder has a read(byte[]) method, it is
possible to implement a Java InputStream on top of a Decoder if one needed to
perform other non-Avro input from the same source. So I cannot currently
imagine an application that could not work with this. Am I missing something?
This should work most of the time except when using a validating or resolving
decoders, where the usage becomes somewhat cumbersome. Since constructing the
grammar is relative expensive, people cache the validating and resolving
decoders. Whenever you want to read avro data out of an input stream, you call
init(inputStream) on the cached ValidatingDecoder(or ResolvingDecoder) and
start reading data off the decoder. Now after consuming the avro data, you
can't directly use the input stream you just passed to read non-avro data, but
fish out the BinaryDecoder wrapper from within the cachced ValidatingDecoder. I
think it's counter-intuitive and hard to explain.
> Performance improvements to BinaryDecoder.readLong()
> ----------------------------------------------------
>
> Key: AVRO-327
> URL: https://issues.apache.org/jira/browse/AVRO-327
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Thiruvalluvan M. G.
> Assignee: Thiruvalluvan M. G.
>
> AVRO-315 proposed performance improvements to readLong(), readFloat() and
> readDouble(). readLong() did not improve performance well for all. Scott
> proposed a better method (but requires a change in semantics and API). We'll
> carry on the discussion on that proposal here. AVRO-315 will be committed
> with changes for readFloat() and readDouble().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
