[
https://issues.apache.org/jira/browse/HBASE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725442#comment-13725442
]
Matt Corgan commented on HBASE-9091:
------------------------------------
On second thought I'm not as worried about prefix-tree performance since it
hasn't been released yet and therefore has no established baseline. I'll
probably go back after .96 is released to make further performance improvements
and can evaluate the impact then. I can easily dig up the old version of
ByteRange if there was an impact, but there's also a chance that ByteRange
isn't even the fastest strategy for prefix-tree.
I'm still worried about mutability. The class was designed to be used
similarly to String, but for bytes instead of chars. Recycling of the object
was the major difference and was to be used with care. If people start using
this new version with mutable position all around the code base, we're going to
run into nasty bugs where methods disagree on who is responsible for position.
> Update ByteRange to maintain consumer's position
> ------------------------------------------------
>
> Key: HBASE-9091
> URL: https://issues.apache.org/jira/browse/HBASE-9091
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Fix For: 0.95.2
>
> 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
