hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14524) Short-circuit comparison of rows in CellComparator
Date Mon, 04 Jan 2016 10:23:39 GMT

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

Anoop Sam John commented on HBASE-14524:

Checked this.  Yes at begin of row we do this.
In StoreScanner#next(List<Cell> outResult, ScannerContext scannerContext), we set the
cur cell as the new row to SQM.
And after this there is a loop to fetch cells for the row and in that every cell is being
matched by SQM.  In that flow, for the 1st cell, it will get compared against itself. 
In Bytes.java there is a short circuit for this.  BBUtils compare method missed that.
By adding this object == check, we can avoid unwanted bytes compare (all bytes of rows) and
type checks.

+1. We can get this in.

> Short-circuit comparison of rows in CellComparator
> --------------------------------------------------
>                 Key: HBASE-14524
>                 URL: https://issues.apache.org/jira/browse/HBASE-14524
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Lars Francke
>            Assignee: Lars Francke
>            Priority: Minor
>         Attachments: HBASE-14524.patch, HBASE-14524.patch
> {{CellComparator#compareRows}} compares two rows. For Scans and Gets these objects can
sometimes be exactly the same object.
> I see this (without fully understanding everything that's going on) for the first cell
in each row.
> In these circumstances I think it makes sense to short-circuit the comparison (not do
a byte comparison and class cast checks) and bail out early if the objects are identical.

This message was sent by Atlassian JIRA

View raw message