[
https://issues.apache.org/jira/browse/AVRO-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785707#action_12785707
]
Scott Carey commented on AVRO-249:
----------------------------------
BigEndian, it appears. Does that fact belong in documentation for the Reflect
API?
On reading, it will be a bit faster if you avoid the array allocation -- at
least until scalar replacement or stack allocation works well in the JVM.
This will not show up in microbenchmarks, but can be rather significant in more
complicated high throughput systems with enough other objects of 'medium'
lifetimes. (The same is true of autoboxing and creating objects members instead
of intrinsic members.)
If you can avoid an allocation and not affect performance or functionality, its
a good idea to do so. This could be done with two one byte reads or by adding
a ByteBuffer - like "readShort()" method to Decoder.
Just to confirm, the "fixed" type doesn't store a length byte, so there is no
extra overhead.
What about char? Its just an unsigned short.
> in reflection, represent Java short as fixed data
> -------------------------------------------------
>
> Key: AVRO-249
> URL: https://issues.apache.org/jira/browse/AVRO-249
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Doug Cutting
> Assignee: Doug Cutting
> Fix For: 1.3.0
>
> Attachments: AVRO-249.patch
>
>
> Currently the Java reflect API treats shorts as ints. This fails however to
> naturally handle shorts in arrays and other containers. It would be better
> if we used a distinct type for reflected Java short values.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
