[
https://issues.apache.org/jira/browse/HBASE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438430#comment-13438430
]
Todd Lipcon commented on HBASE-6621:
------------------------------------
Do you have benchmark results showing an improvement in actual scan speed?
When I looked into scan performance with oprofile a few months back, I found
the same as you -- that a lot of time was spent in these calls. But when I also
added cache miss counters to the profile, I found the reason was cache misses,
not the actual CPU usage of the function. So caching them would just shift
around the cache miss to the next access of the cache line elsewhere, without
actually improving total performance.
> 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
