[
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)
