[
https://issues.apache.org/jira/browse/HBASE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438474#comment-13438474
]
Lars Hofhansl commented on HBASE-6621:
--------------------------------------
I will admit that the improvement is hard to separate from the GC noise.
According to the profiler it should save a about 5%.
When I average out the scan times on the client and let it run for a while I do
see about 2% improvement... Hmm. (note this for v4, with no additional new
caching in KeyValue)
I will also try with a filter that filters everything to eliminate variance in
the driving client.
> 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
