[
https://issues.apache.org/jira/browse/HBASE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729092#comment-13729092
]
Matt Corgan commented on HBASE-9091:
------------------------------------
Sorry - i'm thinking of 2 separate scenarios:
1) Long-lived ByteRanges, such as wrapping a block cache block that may be read
simultaneously by multiple threads. Here I'd argue against the position field
since separate reader threads will each want their own position.
2) High speed, single threaded reuse, such as in prefix-tree encoding where the
ByteRange will be remapped frequently. This is where the volatiles will hurt.
Maybe ByteRange should just be an interface with these different concerns
addressed in different implementations. The sub-classing could introduce a
small performance cost, but it's probably not too bad to begin with, and a lot
of uses will get inlined by the compiler anyway.
> Update ByteRange to maintain consumer's position
> ------------------------------------------------
>
> Key: HBASE-9091
> URL: https://issues.apache.org/jira/browse/HBASE-9091
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Attachments: 0001-HBASE-9091-Extend-ByteRange.patch,
> 0001-HBASE-9091-Extend-ByteRange.patch
>
>
> ByteRange is a useful alternative to Java's ByteBuffer. Notably, it is
> mutable and an instance can be assigned over a byte[] after instantiation.
> This is valuable as a performance consideration when working with byte[]
> slices in a tight loop. Its current design is such that it is not possible to
> consume a portion of the range while performing activities like decoding an
> object without altering the definition of the range. It should provide a
> position that is independent from the range's offset and length to make
> partial reads easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
