[
https://issues.apache.org/jira/browse/HBASE-24850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250103#comment-17250103
]
ramkrishna.s.vasudevan commented on HBASE-24850:
------------------------------------------------
Attached two inlining output generated by adding the
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining.
op_withopt -> is with optimization (with patch), flamegraph_opt -> is with patch
op_withnoopt -> is without the patch, flamegraph.svg -> without patch
You can see that inlining does not happen when there is no patch. But with
patch everthing is inlined. we don't see the 'inlining too deep' case.
I also tried adding the jvm -XX:_MaxInlineLevel_=20 without patch , but that
does not improve as we see with patch case. (though in-lining happens).
> 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)
