[
https://issues.apache.org/jira/browse/HBASE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438445#comment-13438445
]
Lars Hofhansl commented on HBASE-6621:
--------------------------------------
@Todd: I assume you are referring to v3 of the patch? (the part where I suggest
caching the type of the KV and a new byte member) I had the same about this
just being a bogus profiler indicator.
v4 (and v2) does not cache information, it just uses the information that the
HFileScanner already collected anyway (length and key length) and avoids
calculating it again - it cannot make things worse. I saw a real life
improvement with it. I'll quantify it.
> Reduce calls to Bytes.toInt
> ---------------------------
>
> Key: HBASE-6621
> URL: https://issues.apache.org/jira/browse/HBASE-6621
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Minor
> Fix For: 0.96.0, 0.94.2
>
> Attachments: 6621-0.96.txt, 6621-0.96-v2.txt, 6621-0.96-v3.txt,
> 6621-0.96-v4.txt
>
>
> Bytes.toInt shows up quite often in a profiler run.
> It turns out that one source is HFileReaderV2$ScannerV2.getKeyValue().
> Notice that we call the KeyValue(byte[], int) constructor, which forces the
> constructor to determine its size by reading some of the header information
> and calculate the size. In this case, however, we already know the size (from
> the call to readKeyValueLen), so we could just use that.
> In the extreme case of 10000's of columns this noticeably reduces CPU.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
