[
https://issues.apache.org/jira/browse/CASSANDRA-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101956#comment-16101956
]
Benedict commented on CASSANDRA-9988:
-------------------------------------
Right.
That, and my allusion to a "representative complexity" of object are meant to
account for the fact that in C* proper we can expect comparisons to:
# miss L1/2 cache (and on first access all layers of cache; I don't know how
many times we iterate objects, though; almost certainly more than once)
# be costly, as
## we will have many different comparators and object types to compare (so
likely megamorphic call sites and no inlining)
## many of the object will be heavyweight
## neighbouring objects are likely to have lengthy common prefixes, so
comparisons cannot abort early
Since exponential search's main benefit is reducing the number of comparisons,
each of these mischaracterisations is likely to underrepresent its potential in
the wild.
_Ideally_ we should be mitigating these confounders, else our decisions will
potentially be inaccurate.
> Introduce leaf-only iterator
> ----------------------------
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Benedict
> Assignee: Jay Zhuang
> Priority: Minor
> Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-data.png, 9988-result2.png, 9988-result3.png,
> 9988-result.png, 9988-trunk-new.txt, 9988-trunk-new-update.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf
> page. In this case it _may_ be more efficient to specialise our iterator.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
