[jira] [Commented] (CASSANDRA-6271) Replace SnapTree in AtomicSortedColumns

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13857796#comment-13857796 ] 

Jonathan Ellis commented on CASSANDRA-6271:
-------------------------------------------

Pushed review-in-progress to https://github.com/jbellis/cassandra/commits/6271 with cleanup, comments, and fixes.  Bogged down in Stack and Modifier now.

Suspicious that Stack.compareTo ignores forward unless stacks are identical up to min depth.

Confused about ML.copyFrom -- we reset to EMPTY trees, then add elements from other sources.  Is there a better set of names we can use?

Unclear when ML.update returns null.

What is more efficient about ML.build vs calling ML.update(EMPTY_LEAF)?

Is there a minimum number of keys in a branch or leaf?  Are branches/leaves ever combined?  Put another way: are all leaf nodes at the same tree depth?

> Replace SnapTree in AtomicSortedColumns
> ---------------------------------------
>
>                 Key: CASSANDRA-6271
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6271
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>              Labels: performance
>         Attachments: oprate.svg
>
>
> On the write path a huge percentage of time is spent in GC (>50% in my tests, if accounting for slow down due to parallel marking). SnapTrees are both GC unfriendly due to their structure and also very expensive to keep around - each column name in AtomicSortedColumns uses > 100 bytes on average (excluding the actual ByteBuffer).
> I suggest using a sorted array; changes are supplied at-once, as opposed to one at a time, and if < 10% of the keys in the array change (and data equal to < 10% of the size of the key array) we simply overlay a new array of changes only over the top. Otherwise we rewrite the array. This method should ensure much less GC overhead, and also save approximately 80% of the current memory overhead.
> TreeMap is similarly difficult object for the GC, and a related task might be to remove it where not strictly necessary, even though we don't keep them hanging around for long. TreeMapBackedSortedColumns, for instance, seems to be used in a lot of places where we could simply sort the columns.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)