hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Corgan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9091) Update ByteRange to maintain consumer's position
Date Tue, 30 Jul 2013 22:37:49 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724533#comment-13724533

Matt Corgan commented on HBASE-9091:

I don't disagree with the need for something like this, but it's changing the goals of the
class substantially from what it's designed for.  This is used as an ultra-lightweight wrapper
for byte[]'s in the tightest loops of the prefix-tree codec where just a few extra operations
like clearing a field or doing a bounds check have a measurable impact on MB/s througput.
 While I don't have a benchmark at hand, all the Preconditions.checkXyz(..) bounds checks
worry me.

Maybe an alternative is to rename the existing version PrefixTreeByteRange and move it over
to the prefix-tree module.  Then these changes won't affect prefix-tree performance.  I probably
shouldn't have put it in the base hbase-client module anyway since it's so sensitive to changes.
> 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
> 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

View raw message