[
https://issues.apache.org/jira/browse/AVRO-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800841#action_12800841
]
Doug Cutting commented on AVRO-327:
-----------------------------------
Your first case adds a single line of code, which isn't bad for consistently
providing improved performance. The alternative (a non-buffering
BinaryDecoder) would save a line of code but force such applications to perform
more slowly.
The second case can also be handled with the addition of single line of code:
{code}
void f(InputStream in) {
BinaryDecoder bin = new BinaryDecoder(in);
AvroObject o = readAvro(bin);
NonAvroObject no = readNonAvro(new BinaryDecoderInputStream(bin));
}
{code}
If Decoder were made an interface, then a BinaryDecoder could also be an
InputStream, so no additional lines of code would be required.
In any case, we don't have to argue about this forever. If you feel strongly,
then we can add this as BufferedBinaryDecoder and then update all uses within
Avro to use it in place of BinaryDecoder, so that we provide better
performance, and add a caution to BinaryDecoder stating that
BufferedBinaryDecoder should be used for best performance.
Should I prepare a patch or would you like to? Scott?
> 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.
