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

Benedict commented on CASSANDRA-6271:
-------------------------------------

That's exactly what will happen. Note that if we aren't already in the root\* 
then when we ascend we will infact increment the pointer and exit if we aren't 
at the end.

Specifically, in this case, we would execute:
{noformat}
        while(!isRoot())                True
          pop()                         now on [18,24,29,32]
          i = currentIndex() + 1        i = 4
          node = currentNode();
          if (i < getKeyEnd(node))      getKeyEnd(node) == 4 => False
        while(!isRoot())                True
          pop()                         now on [8,14,37,52]
          i = currentIndex() + 1        i = 3
          node = currentNode();
          if (i < getKeyEnd(node))      getKeyEnd(node) == 4 => True
          setIndex(3);
          return
{noformat}

\*if we are, we must be at the end, so we're done anyway

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

Reply via email to