[
https://issues.apache.org/jira/browse/HBASE-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818605#comment-13818605
]
Lars Hofhansl commented on HBASE-9935:
--------------------------------------
Did more some tests.
The steady state of this is even improved when I remove the keyLength caching
from KeyValue. I my case I do full scans through 25m KVs, so in each run the
extra keyLength cache produces 100mb of extra garbage to be collected.
I also observed a slight slowdown (mostly within the noise, though) in this
scenario when I do the 2 byte rowLength caching.
So my proposal is this:
# remove the keyLength caching
# look through the callers of getFamilyOffset/getFamilyLength, etc, and see
where we can optimize this while hiding all of this in the KeyValue class
# no cache for the rowLength
> Slight perf improvement: Avoid KeyValue.getRowLength() at some places
> ---------------------------------------------------------------------
>
> Key: HBASE-9935
> URL: https://issues.apache.org/jira/browse/HBASE-9935
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
>
> Here's an example:
> {code}
> KeyValue.createLastOnRow(
> kv.getBuffer(), kv.getRowOffset(), kv.getRowLength(),
> kv.getBuffer(), kv.getFamilyOffset(), kv.getFamilyLength(),
> kv.getBuffer(), kv.getQualifierOffset(), kv.getQualifierLength());
> {code}
> Looks harmless enough, but that actually recalculates the rowlength 5 times.
> And each time it needs to decode the rowlength again from the bytes of the KV.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
