[ https://issues.apache.org/jira/browse/HBASE-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393489#comment-15393489 ]
Anoop Sam John commented on HBASE-15721: ---------------------------------------- [~saint....@gmail.com] Any objection in making the above scope change for MSLAB? Than just allocate bytes, it will do allocation + copy and recreation of the cell. This is required in the CompactingMemstore flatten to CellChunkMap. In this flattened form, we wont be having Cell objects. We will keep cell's meta data that it is in which chunk and at what offset. Normally from a KeyValue we wont get any info like chunkId. So if we allow this change, then the MSLAB impl can create a new Cell impl which keeps the chunkId also. I need to rework on the patch any way. Now there is a way not to add write() to Streamable > Optimization in cloning cells into MSLAB > ---------------------------------------- > > Key: HBASE-15721 > URL: https://issues.apache.org/jira/browse/HBASE-15721 > Project: HBase > Issue Type: Sub-task > Components: regionserver > Reporter: Anoop Sam John > Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15721.patch, HBASE-15721_V2.patch > > > Before cells added to memstore CSLM, there is a clone of cell after copying > it to MSLAB chunk area. This is done not in an efficient way. > {code} > public static int appendToByteArray(final Cell cell, final byte[] output, > final int offset) { > int pos = offset; > pos = Bytes.putInt(output, pos, keyLength(cell)); > pos = Bytes.putInt(output, pos, cell.getValueLength()); > pos = appendKeyTo(cell, output, pos); > pos = CellUtil.copyValueTo(cell, output, pos); > if ((cell.getTagsLength() > 0)) { > pos = Bytes.putAsShort(output, pos, cell.getTagsLength()); > pos = CellUtil.copyTagTo(cell, output, pos); > } > return pos; > } > {code} > Copied in 9 steps and we end up parsing all lengths. When the cell > implementation is backed by a single byte[] (Like KeyValue) this can be done > in single step copy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)