[
https://issues.apache.org/jira/browse/HBASE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729655#comment-13729655
]
Nick Dimiduk commented on HBASE-9091:
-------------------------------------
[~stack] Since we're not running on flintstones computers, my preference is to
use a single class that wraps both a range in a byte[] and a position marker, a
la {{ByteBuffer}}.
[~mcorgan] Having ready through Guava's {{Precondition}} code, I'm not as
concerned about the performance impact of the additional checks. I don't have a
microbenchmark to quantify the lack of concern, but the code describes the
pains taken to shape the condition checking statements for the benefit of the
JIT, at least not in the face of giving helpful feedback in a user-facing API.
[~mcorgan] Thanks for outlining your two use-cases above, that's helpful. I
think my intended use-case is an extension of #2, where position tracking is
the added feature. I can't think of a case where a user would want to build a
compound rowkey across multiple threads.
I'll assemble a new patch that leaves {{ByteRange}} intact, extending it with a
subclass that adds the position tracking. I will omit the precondition checking
for the time being, so long as we all understand that (1) omission opens the
user up to easily detected bugs and (2) adding it later will impact a
(admittedly brand new, {{Evolving}}) public API.
I will not update the other two patches until we've found something here that's
agreeable. I'd rather ship 8201 and 8693 as they are than miss the window
because of this bit of API sugar.
> 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
