[
https://issues.apache.org/jira/browse/HBASE-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818256#comment-13818256
]
Lars Hofhansl commented on HBASE-9935:
--------------------------------------
[~jmspaggi], caching stuff because of a profiler session is itself an anti
pattern. See HBASE-7279 where I removed a bunch of stuff that we cached. Now,
we never cached the rowLength before and it is only short, so it might be OK.
I also want rationalize all these static methods we have on KeyValue. The
particular one I quote in the description should be an object method - and
interestingly there *is* a method on KeyValue that does exactly that call
createLastOnRowCol. If we use these or similar methods everywhere we can hide
the KeyValue specific optimizations inside KeyValue while still not requiring a
cache of 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)
