[
https://issues.apache.org/jira/browse/CASSANDRA-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221525#comment-13221525
]
Jonathan Ellis commented on CASSANDRA-3952:
-------------------------------------------
Good idea. It kind of balances out, since if there's a lot of sstables that
*aren't* in the manifest, then the manifest will be smaller and the
{{contains}} calls correspondingly faster.
I'd rather avoid adding compactionstrategy-specific fields elsewhere if we can
help it, but I think we can get the same effect with a temporary {{Map<sstable,
level>}} or even just {{Set<sstable>}} that we build during manifest creation?
> avoid quadratic startup time in LeveledManifest
> -----------------------------------------------
>
> Key: CASSANDRA-3952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3952
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Priority: Minor
> Labels: lhf
> Fix For: 1.1.1
>
>
> Checking that each sstable is in the manifest on startup is O(N**2) in the
> number of sstables:
> {code}
> . // ensure all SSTables are in the manifest
> for (SSTableReader ssTableReader : cfs.getSSTables())
> {
> if (manifest.levelOf(ssTableReader) < 0)
> manifest.add(ssTableReader);
> }
> {code}
> {code}
> private int levelOf(SSTableReader sstable)
> {
> for (int level = 0; level < generations.length; level++)
> {
> if (generations[level].contains(sstable))
> return level;
> }
> return -1;
> }
> {code}
> Note that the contains call is a linear List.contains.
> We need to switch to a sorted list and bsearch, or a tree, to support
> TB-levels of data in LeveledCompactionStrategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
