[
https://issues.apache.org/jira/browse/HBASE-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947544#comment-13947544
]
Anoop Sam John commented on HBASE-10771:
----------------------------------------
bq. Now we have to have two code paths... one for those with backing byte
arrays and then another for those offheap?
That need not be. Now we have put/get APIs in BR. so the impl can know
whether it is on heap or offheap and do the best way of put/get.
Another thing can be the comprator. Here also we can come up with a comparator
and it can have one code path only which can work with offheap also.
Adding of this kind of an API will allow some one to have 2 code paths *if
needed*..
As u can see in the path, the put(BR) itself uses this new API. When it is
onheap (the src BR) System.arrayCopy can be the best way of copy rather than
byte by byte assign (?) When on heap we have no such choice..
So we wont have 2 code paths based on this.. But may be at some use places we
*can have also* like above case. (Now or later)
How that sounds Stack?
> Primitive type put/get APIs in ByteRange
> -----------------------------------------
>
> Key: HBASE-10771
> URL: https://issues.apache.org/jira/browse/HBASE-10771
> Project: HBase
> Issue Type: Improvement
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 0.99.0
>
> Attachments: HBASE-10771.patch, HBASE-10771_V2.patch
>
>
> While doing HBASE-10713 I came across the need to write int/long (and read
> also) from a ByteRange. CellBlocks are backed by ByteRange. So we can add
> such APIs.
> Also as per HBASE-10750 we return a ByteRange from MSLAB and also discussion
> under HBASE-10191 suggest we can have BR backed HFileBlocks etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
