[
https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557541#comment-14557541
]
Lars Hofhansl commented on HBASE-13448:
---------------------------------------
It's just a straight scan end-to-end. If you promise to not judge on the hacked
up code I'll post it here (maybe I'll clean it up some).
So it's entirely possible that we do many more calls to getRowLength and friend
in trunk, and that that would tip the scale in favor of the patch.
Just passing Cells to the comparators - as we do in trunk now - is certainly
much nicer. In the past I have usually not pursued optimization that yielded a
< 5% improvement. Can we look at the comparators and see if we can modify them
such that they are more cache line friendly (i.e. not jumping around in the
backing byte[]).
After all my previous testing I am biased now, but I feel that caching things
like these just work around the issue.
> New Cell implementation with cached component offsets/lengths
> -------------------------------------------------------------
>
> Key: HBASE-13448
> URL: https://issues.apache.org/jira/browse/HBASE-13448
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: 13448-0.98.txt, HBASE-13448.patch, HBASE-13448_V2.patch,
> HBASE-13448_V3.patch, gc.png, hits.png
>
>
> This can be extension to KeyValue and can be instantiated and used in read
> path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
