[ 
https://issues.apache.org/jira/browse/HBASE-24850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250696#comment-17250696
 ] 

Andrew Kyle Purtell commented on HBASE-24850:
---------------------------------------------

bq.  @ 26   org.apache.hadoop.hbase.CellComparatorImpl::compare (1332 bytes)   
hot method too big

I believe the limit on 64 bit Linux is 325 bytecode instructions. 

Norman Maurer (of Netty fame) offers refactoring advice in this case here: 
http://normanmaurer.me/blog/2014/05/15/Inline-all-the-Things/ . Essentially:
{quote}
But how to shorten them without loosing functionality? The solution is to move 
"less common patterns" out of the method into another method. This way the 
method itself becomes smaller while still be able to cover everything by the 
cost of dispatch to another method. 
{quote}

You want the essential "happy path" compare to be small enough to inline. Break 
out special cases to other methods (which will be dispatched for the special 
cases).

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. 

> 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)

Reply via email to