[
https://issues.apache.org/jira/browse/HBASE-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510266#comment-13510266
]
stack commented on HBASE-7279:
------------------------------
I don't care about whether it pretty or not. Its fine writing a bit more code
for some savings. How you think we test more if we are losing out by removing
the row and ts caches?
Patch looks good.
Could peeked change under you while you do the below? Or is it single thread
only in here?
+ byte[] row = peeked.getBuffer();
+ int offset = peeked.getRowOffset();
+ short length = peeked.getRowLength();
> Avoid copying the rowkey in RegionScanner, StoreScanner, and ScanQueryMatcher
> -----------------------------------------------------------------------------
>
> Key: HBASE-7279
> URL: https://issues.apache.org/jira/browse/HBASE-7279
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 7279-0.94.txt
>
>
> Did some profiling again.
> I we can gain some performance [1] when passing buffer, rowoffset, and
> rowlength instead of making a copy of the row key.
> That way we can also remove the row key caching (and this patch also removes
> the timestamps caching). Considering the sheer number in which we create KVs,
> every byte save is good.
> [1] (15-20% when data is in the block cache we setup a Filter such that only
> a single row is returned to the client).
--
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
