[
https://issues.apache.org/jira/browse/HBASE-17644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866066#comment-15866066
]
stack commented on HBASE-17644:
-------------------------------
Patch is a nice cleanup. +1. Only beef is my usual... see below..... Hopefully
we can get rid of these one day.
{code}
3191 if (tagsLen == 0) {
3192 // When tagsLen is 0, make a NoTagsByteBufferKeyValue version.
This is an optimized class
3193 // which directly return tagsLen as 0. So we avoid parsing many
length components in
3194 // reading the tagLength stored in the backing buffer. The
Memstore addition of every Cell
3195 // call getTagsLength().
3196 return new NoTagsByteBufferKeyValue(buf, offset, len,
cell.getSequenceId());
3197 } else {
3198 return new ByteBufferKeyValue(buf, offset, len,
cell.getSequenceId());
3204 } 3199 }
{code}
> Always create ByteBufferCells after copying to MSLAB
> ----------------------------------------------------
>
> Key: HBASE-17644
> URL: https://issues.apache.org/jira/browse/HBASE-17644
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Affects Versions: 2.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-17644.patch
>
>
> We create a cell out of the Bytebuffer that is returned by MSLAB. This BB can
> be offheap or onheap type. If MSLAB is full we return onheap byte buffer. So
> the place where we create a cell by copying data to this buffer we either
> create KeyValue or OffheapKV based on the buffer type. So what we saw in
> tests is that since we have a combination of Cells the comparisons that
> happens when adding to memstore happens millions of times and that has an
> impact on the performance of write path. In read path this is not significant
> enougth (though we have plans to just create one type of cells every where in
> Server side).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
