hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-3928) Some potential performance improvements to Bytes/KeyValue
Date Fri, 27 May 2011 18:50:47 GMT

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

stack commented on HBASE-3928:

+1 on commit to TRUNK.  Can only improve things.  We'll be profiling 0.92 before commit so
if a problem, a newly-introduced hotspot, we'll see it then (I'd doubt that this optimization
would show in YCSB -- not unless it made stuff really bad, or really good which I don't think
is going to be happening here).

Odd we don't cache this Bytes.toBytes("MAX_SEQ_ID_KEY") and the other TIMERANGE constant that

> Some potential performance improvements to Bytes/KeyValue
> ---------------------------------------------------------
>                 Key: HBASE-3928
>                 URL: https://issues.apache.org/jira/browse/HBASE-3928
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.92.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Minor
>             Fix For: 0.92.0
>         Attachments: hbase-3928.txt
> We use Bytes.compareTo() a lot where we could be using a more efficient equals() method.
The trick that makes equals() faster than compareTo is that we can short-circuit two common
> Case 1) the length is not the same - only need to do one comparison
> Case 2) the two arrays have the same length and a common prefix: compare the last byte
first, since it's the one most likely to differ (given we are usually comparing adjacent sorted

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message