[jira] [Commented] (HBASE-9091) Update ByteRange to maintain consumer's position

["Nick Dimiduk (JIRA)" <ji...@apache.org>]

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

Nick Dimiduk commented on HBASE-9091:
-------------------------------------

I can remove the ByteBuffer/ByteRange dependency from OrderedBytes entirely if I separate decoding a value from advancing the cursor. The client API then becomes

{noformat}
Foo[] foos = new Foo[] { new Foo (1), new Foo(2) };
byte[] a = new byte[...];

// encode values
for (int i = 0, position = 0; i < foos.length; i++) {
  position = OrderedBytes.encodeFoo(a, position, foos[i]);
}

// decode values
ArrayList<Foo> decoded = new ArrayList<Foo>();
for (int position = 0; position < a.length;) {
  decoded.add(OrderedBytes.decodeFoo(a, position));
  position = OrderedBytes.skip(a, position);
}
{noformat}

{{decodeFoo}} cannot return both a value and the updated position (hence the use of ByteBuffer or modified ByteRange), so it returns the value and throws away the new position. With this API, the range of bytes which encodes a value must be scanned twice, but it removes the dependency on managing the position state in the codec. The scan used in skip is faster than the decode operation, but it's still an additional {{O\(n)}} operation where {{n}} is the length of the encoded value.

What do you think about this solution?
                
> 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