[
https://issues.apache.org/jira/browse/HBASE-17484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828886#comment-15828886
]
stack commented on HBASE-17484:
-------------------------------
Any evidence to present to justify why we should have these new types? We've
gone this route a bunch of times in our history adding caching and then undoing
it. The argument is that reading these lengths by parsing offheap bytes is
slow?
After this patch, how many versions of KeyValue do we have?
Do we have to have a OffheapKeyValue and Cached... ? Do we have to realize the
storage in the Type? Isn't it enough having a ByteBufferCell with it internally
doing direct or non-direct?
This looks odd... private static final int FIXED_OVERHEAD =
39 OffheapKeyValue.FIXED_OVERHEAD + +Bytes.SIZEOF_INT +
Bytes.SIZEOF_SHORT; .... is that a double '+'?
> Add non cached version of OffheapKV for write path
> --------------------------------------------------
>
> Key: HBASE-17484
> URL: https://issues.apache.org/jira/browse/HBASE-17484
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Affects Versions: 2.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-17484.patch
>
>
> After running lot of different performance tests for various scenarios and
> with multi threads we thought that is better to have a version of OffheapKV
> in write path that does not cache anything and its fixed_overhead is equal to
> that in KeyValue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
