Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 20 Mar 2015 14:32:52 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12782908.1426695205000.156901.1426861972024@Atlassian.JIRA>
In-Reply-To: <JIRA.12782908.1426695205000@Atlassian.JIRA>
References: <JIRA.12782908.1426695205000@Atlassian.JIRA>
 <JIRA.12782908.1426695205496@arcas>
Subject: [jira] [Commented] (CASSANDRA-8988) Optimise IntervalTree
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Benedict commented on CASSANDRA-8988:
-------------------------------------

compare() would erase to the same function, so we have to call it something else. We could call it asymCompare() or something, but I felt compare2 was no uglier. binarySearch we could switch, for sure, although I don't totally like calling it that when the semantics are different (don't mind too much though), but we will have the same namespace clash if we ever provide the improved semantics for non-asymmetric comparisons, so it would have to be asymBinarySearch or binarySearch2, or whatever.

Got better suggestions for inclusivei, returni, search and find? I thought they were pretty descriptive! 

find == thing to find
search == thing to search (in) - i suppose you could suffix that with (for) in your head, but it would be atypical usage.

Perhaps searchIn and searchFor? Matching binarySearch nomenclature more closely as well

inclusivei / returni i'm just not sure how to improve very much. If you think it's clearer we could defer to a member variable for these, although actually i would find that harder to read (the formal proofs are also inline in the methods). We could certainly transform returni() back to result(), but thought it better mirrored selecti() as stands. Perhaps selecti() could be compareComparisonResultTo() and returns the bound we compare against directly?

> Optimise IntervalTree
> ---------------------
>
>                 Key: CASSANDRA-8988
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8988
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>             Fix For: 3.0
>
>         Attachments: 8988.txt
>
>
> We perform a lot of unnecessary comparisons in IntervalTree.IntervalNode.searchInternal.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)