[jira] [Commented] (CASSANDRA-6692) AtomicBTreeColumns Improvements

2014-03-12 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932634#comment-13932634
 ] 

Jonathan Ellis commented on CASSANDRA-6692:
---

Strongly dislike this pattern:

{code}
if (updateF == null)
updateF = UpdateFunction.NoOp.instance();
{code}

Prefer not modifying parameters (making caller pass NoOp) and optionally adding 
an assert to make it obvious.  Will commit with that change.

 AtomicBTreeColumns Improvements
 ---

 Key: CASSANDRA-6692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
Priority: Minor
  Labels: easyfix, performance
 Fix For: 2.1 beta2

 Attachments: 6692.3.txt, 6692.fix, patch.txt


 There are two improvements to make to the BTree code that should help:
 1) It turns out Stack Allocation is more rubbish than we had hoped, and so 
 the fast route actually allocates garbage. It's unlikely this reduces 
 throughput, but the increased young-gen pressure is probably unwelcome. I 
 propose to remove the fast route for now.
 2) It is not uncommon to race to perform an update, so that the new values 
 are actually out-of-date when we come to modify the tree. In this case the 
 update should recognise that the original (portion of) the tree has not been 
 modified, and simply return it, without allocating a new one.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (CASSANDRA-6692) AtomicBTreeColumns Improvements

2014-03-12 Thread Benedict (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932641#comment-13932641
 ] 

Benedict commented on CASSANDRA-6692:
-

Good point.

 AtomicBTreeColumns Improvements
 ---

 Key: CASSANDRA-6692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
Priority: Minor
  Labels: easyfix, performance
 Fix For: 2.1 beta2

 Attachments: 6692.3.txt, 6692.fix, patch.txt


 There are two improvements to make to the BTree code that should help:
 1) It turns out Stack Allocation is more rubbish than we had hoped, and so 
 the fast route actually allocates garbage. It's unlikely this reduces 
 throughput, but the increased young-gen pressure is probably unwelcome. I 
 propose to remove the fast route for now.
 2) It is not uncommon to race to perform an update, so that the new values 
 are actually out-of-date when we come to modify the tree. In this case the 
 update should recognise that the original (portion of) the tree has not been 
 modified, and simply return it, without allocating a new one.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (CASSANDRA-6692) AtomicBTreeColumns Improvements

2014-03-12 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932660#comment-13932660
 ] 

Jonathan Ellis commented on CASSANDRA-6692:
---

committed

 AtomicBTreeColumns Improvements
 ---

 Key: CASSANDRA-6692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
Priority: Minor
  Labels: easyfix, performance
 Fix For: 2.1 beta2

 Attachments: 6692.3.txt, 6692.fix, patch.txt


 There are two improvements to make to the BTree code that should help:
 1) It turns out Stack Allocation is more rubbish than we had hoped, and so 
 the fast route actually allocates garbage. It's unlikely this reduces 
 throughput, but the increased young-gen pressure is probably unwelcome. I 
 propose to remove the fast route for now.
 2) It is not uncommon to race to perform an update, so that the new values 
 are actually out-of-date when we come to modify the tree. In this case the 
 update should recognise that the original (portion of) the tree has not been 
 modified, and simply return it, without allocating a new one.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (CASSANDRA-6692) AtomicBTreeColumns Improvements

2014-02-19 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13906400#comment-13906400
 ] 

Aleksey Yeschenko commented on CASSANDRA-6692:
--

This seems to have broken a bunch of tests (getting NPE from isLeaf()).

For example,
{noformat}
[junit] Testcase: 
testIndexUpdate(org.apache.cassandra.db.ColumnFamilyStoreTest):   Caused an 
ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at org.apache.cassandra.utils.btree.BTree.isLeaf(BTree.java:302)
[junit] at 
org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:131)
[junit] at 
org.apache.cassandra.utils.btree.Builder.update(Builder.java:74)
[junit] at org.apache.cassandra.utils.btree.BTree.update(BTree.java:157)
[junit] at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:254)
[junit] at org.apache.cassandra.db.Memtable.put(Memtable.java:195)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1096)
[junit] at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:370)
[junit] at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:328)
[junit] at org.apache.cassandra.db.Mutation.apply(Mutation.java:205)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStoreTest.testIndexUpdate(ColumnFamilyStoreTest.java:389)
{noformat}

 AtomicBTreeColumns Improvements
 ---

 Key: CASSANDRA-6692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
Priority: Minor
  Labels: easyfix, performance
 Fix For: 2.1


 There are two improvements to make to the BTree code that should help:
 1) It turns out Stack Allocation is more rubbish than we had hoped, and so 
 the fast route actually allocates garbage. It's unlikely this reduces 
 throughput, but the increased young-gen pressure is probably unwelcome. I 
 propose to remove the fast route for now.
 2) It is not uncommon to race to perform an update, so that the new values 
 are actually out-of-date when we come to modify the tree. In this case the 
 update should recognise that the original (portion of) the tree has not been 
 modified, and simply return it, without allocating a new one.



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


[jira] [Commented] (CASSANDRA-6692) AtomicBTreeColumns Improvements

2014-02-17 Thread Benedict (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903667#comment-13903667
 ] 

Benedict commented on CASSANDRA-6692:
-

Are you sure? It doesn't appear to be applied to trunk, and I can't see the 
commit message in my email history

 AtomicBTreeColumns Improvements
 ---

 Key: CASSANDRA-6692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
Priority: Minor
  Labels: easyfix, performance
 Fix For: 2.1


 There are two improvements to make to the BTree code that should help:
 1) It turns out Stack Allocation is more rubbish than we had hoped, and so 
 the fast route actually allocates garbage. It's unlikely this reduces 
 throughput, but the increased young-gen pressure is probably unwelcome. I 
 propose to remove the fast route for now.
 2) It is not uncommon to race to perform an update, so that the new values 
 are actually out-of-date when we come to modify the tree. In this case the 
 update should recognise that the original (portion of) the tree has not been 
 modified, and simply return it, without allocating a new one.



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


[jira] [Commented] (CASSANDRA-6692) AtomicBTreeColumns Improvements

2014-02-17 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903714#comment-13903714
 ] 

Jonathan Ellis commented on CASSANDRA-6692:
---

re-committed and pushed this time.

 AtomicBTreeColumns Improvements
 ---

 Key: CASSANDRA-6692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: Benedict
Priority: Minor
  Labels: easyfix, performance
 Fix For: 2.1


 There are two improvements to make to the BTree code that should help:
 1) It turns out Stack Allocation is more rubbish than we had hoped, and so 
 the fast route actually allocates garbage. It's unlikely this reduces 
 throughput, but the increased young-gen pressure is probably unwelcome. I 
 propose to remove the fast route for now.
 2) It is not uncommon to race to perform an update, so that the new values 
 are actually out-of-date when we come to modify the tree. In this case the 
 update should recognise that the original (portion of) the tree has not been 
 modified, and simply return it, without allocating a new one.



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