[
https://issues.apache.org/jira/browse/HBASE-9969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826238#comment-13826238
]
Lars Hofhansl commented on HBASE-9969:
--------------------------------------
[~mcorgan]
Interestingly I also do not see any measurable performance gain from removing
that check.
This does not seem too surprising. If current was the last scanner on the heap,
adding it back causes no extra comparison, neither does pollRealKV do any
appreciable work. If there is only scanner it will be returned in the first
iteration of the loop (and might do a real seek in that process, which is
necessary for lazy seek).
Do have data for the number of comparisons.
[~jmhsieh] I agree. We can let this stew (if we want) in trunk for a bit and
then decide about backports. I'll remove 0.94 from the fix targets.
> Improve KeyValueHeap using loser tree
> -------------------------------------
>
> Key: HBASE-9969
> URL: https://issues.apache.org/jira/browse/HBASE-9969
> Project: HBase
> Issue Type: Improvement
> Components: Performance, regionserver
> Reporter: Chao Shi
> Assignee: Chao Shi
> Fix For: 0.98.0, 0.96.1
>
> Attachments: 9969-0.94.txt, hbase-9969-v2.patch, hbase-9969-v3.patch,
> hbase-9969.patch, hbase-9969.patch, kvheap-benchmark.png, kvheap-benchmark.txt
>
>
> LoserTree is the better data structure than binary heap. It saves half of the
> comparisons on each next(), though the time complexity is on O(logN).
> Currently A scan or get will go through two KeyValueHeaps, one is merging KVs
> read from multiple HFiles in a single store, the other is merging results
> from multiple stores. This patch should improve the both cases whenever CPU
> is the bottleneck (e.g. scan with filter over cached blocks, HBASE-9811).
> All of the optimization work is done in KeyValueHeap and does not change its
> public interfaces. The new code looks more cleaner and simpler to understand.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
