[
https://issues.apache.org/jira/browse/CASSANDRA-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367949#comment-14367949
]
Benedict commented on CASSANDRA-8988:
-------------------------------------
My goal here was to keep the code behaviour largely unmodified, but since
leaving the order of operands intact let me swap the early termination clauses
I've fixed the ordering of the parameters to be consistent as you suggest.
Since we only build the reverse ordering indrection on construction, and the
normal ordering is useful for CASSANDRA-8920, I'm inclined to leave that as is.
As to binary search, I agree in principle, but in practice we need to implement
an asymmetric binary search (i.e. can accept different types on each side). The
benefit will be determined by the average size of these lists, which I'm not
all too clear on. With STCS it could well be very large, so might be helpful.
> 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: Trivial
> Fix For: 2.1.4
>
> 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)
