[
https://issues.apache.org/jira/browse/AVRO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993158#comment-12993158
]
Scott Carey commented on AVRO-753:
----------------------------------
Thanks Thiru, it is making more sense now. I've gotten BlockingBinaryEncoder
integrated with my changes and it shares more code with BinaryEncoder.
I'm nearly done here, but have found lots of bugs in Avro and our tests as a
result. In most places, we assume that BinaryEncoder does not buffer. These
are bugs because the Encoder contract calls out that it may buffer, and has a
flush() method. JsonEncoder, BlockingBinaryEncoder, and some corner cases of
BinaryEncoder do buffer, and there are several bits of code that have an
Encoder object that is used without calling flush().
> Java: Improve BinaryEncoder Performance
> ----------------------------------------
>
> Key: AVRO-753
> URL: https://issues.apache.org/jira/browse/AVRO-753
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Scott Carey
> Assignee: Scott Carey
> Fix For: 1.5.0
>
> Attachments: AVRO-753.v1.patch
>
>
> BinaryEncoder has not had a performance improvement pass like BinaryDecoder
> did. It still mostly writes directly to the underlying OutputStream which is
> not optimal for performance. I like to use a rule that if you are writing to
> an OutputStream or reading from an InputStream in chunks smaller than 128
> bytes, you have a performance problem.
> Measurements indicate that optimizing BinaryEncoder yields a 2.5x to 6x
> performance improvement. The process is significantly simpler than
> BinaryDecoder because 'pushing' is easier than 'pulling' -- and also because
> we do not need a 'direct' variant because BinaryEncoder already buffers
> sometimes.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
