[
https://issues.apache.org/jira/browse/HBASE-24850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249838#comment-17249838
]
Michael Stack commented on HBASE-24850:
---------------------------------------
bq. When we use a file system based cache even there is i KV only. And anyway
the keys that gets added to the memstore are purely KV only.
nod. Thanks.
bq. Can we have compare(Cell) in ExtendedCell?
I think [~ram_krish] is good on why not to do the above.
Lets get this JIRA landed. Next would be fixing this stack trace of
[~ram_krish]'s from the previous issue
https://issues.apache.org/jira/browse/HBASE-24754?focusedCommentId=17172541&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17172541
The difference in the stack trace is extreme between hbase1 and hbase2; if
all is inlined, then they are the same.... if they are not, there is an
opportunity for speedup collapsing the #compare.
> 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
>
>
> 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)
