[
https://issues.apache.org/jira/browse/HBASE-24850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175247#comment-17175247
]
Anoop Sam John commented on HBASE-24850:
----------------------------------------
{code}
if (a instanceof ByteBufferKeyValue && b instanceof ByteBufferKeyValue) {
diff = BBKVComparator.compare((ByteBufferKeyValue)a,
(ByteBufferKeyValue)b, ignoreSequenceid);
if (diff != 0) {
return diff;
}
} else {
diff = compareRows(a, b);
if (diff != 0) {
return diff;
}
diff = compareWithoutRow(a, b);
if (diff != 0) {
return diff;
}
}
{code}
If the Cells are BBKV, we have a BBKVComparator path which is having
optimizations and avoid decoding the offset/length many times. But when normal
read path where we get KVs we follow the else block and end up doing the
offset/length decoding many a times. In HBASE-24754, that is what Ram's test
revealed.
At 1st we can try optimizing this else code path and avoid these decoding again
and again but instead reuse already decoded values. Then we can see
whether/how we can make a CellComparator type for Cells backed by contiguous
data structure (byte[]/BB)
> 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: 2.4.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)
