[ 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)