cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8988) Optimise IntervalTree
Date Fri, 20 Mar 2015 14:32:52 GMT


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

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:
>             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

View raw message