[
https://issues.apache.org/jira/browse/HBASE-24850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250809#comment-17250809
]
ramkrishna.s.vasudevan commented on HBASE-24850:
------------------------------------------------
bq.If there is not a single "happy path" then you want separate comparator
methods for each case, each small enough to be inlined, and let the JIT figure
out by runtime profiling which comparator method call can be predicted and
inlined.
Thansks [~apurtell]. Let me see if we can reduce that too.
> CellComparator perf improvement
> -------------------------------
>
> Key: HBASE-24850
> URL: https://issues.apache.org/jira/browse/HBASE-24850
> Project: HBase
> Issue Type: Improvement
> Components: Performance, scan
> Affects Versions: 2.0.0
> Reporter: Anoop Sam John
> Assignee: ramkrishna.s.vasudevan
> Priority: Critical
> Fix For: 3.0.0-alpha-1, 2.5.0
>
> Attachments: flamegraph.svg, flamegraph_opt.svg, op_withnoopt,
> op_withopt
>
>
> We have multiple perf issues in 2.x versions compared to 1.x. Eg:
> HBASE-24754, HBASE-24637.
> The pattern is clear that where ever we do more and more Cell compares, there
> is some degrade. In HBASE-24754, with an old KVComparator style comparator,
> we see much better perf for the PutSortReducer. (Again the gain is huge
> because of large number of compare ops that test is doing). This issue is to
> address and optimize compares generally in CellComparatorImpl itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
