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