[
https://issues.apache.org/jira/browse/CASSANDRA-8414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-8414:
--------------------------------
Attachment: cassandra-2.0-8414-3.txt
Nice backporting of the better approach.
I've uploaded a tweaked version, the goal of which was just to clean up the
variable names (and switch to a while loop) so it's more obvious what's
happening. But while at it I also added use of nextClearBit in tandem with
nextSetBit, as it's a minor tweak but gives better behaviour with runs of
adjacent removes.
I haven't properly reviewed otherwise, but it might be worth introducing this
to CFS.removeDroppedColumns() and SliceQueryFilter.trim(),
> Avoid loops over array backed iterators that call iter.remove()
> ---------------------------------------------------------------
>
> Key: CASSANDRA-8414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8414
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Richard Low
> Assignee: Jimmy Mårdell
> Labels: performance
> Fix For: 2.1.3
>
> Attachments: cassandra-2.0-8414-1.txt, cassandra-2.0-8414-2.txt,
> cassandra-2.0-8414-3.txt
>
>
> I noticed from sampling that sometimes compaction spends almost all of its
> time in iter.remove() in ColumnFamilyStore.removeDeletedStandard. It turns
> out that the cf object is using ArrayBackedSortedColumns, so deletes are from
> an ArrayList. If the majority of your columns are GCable tombstones then this
> is O(n^2). The data structure should be changed or a copy made to avoid this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
