[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908605#comment-13908605 ]
Benedict commented on CASSANDRA-6694: ------------------------------------- So, at the very least we use it on each read when we return the clustering columns. We also do this for the value itself; also in KeySearcher and CompositeSearcher whilst filtering; and DecoratedKey.key() is called in a _lot_ of places. This _may_ also make the comparison code a little unpleasant (maybe not, also, but we have a few different kinds of comparison to deal with, and we need to make sure there's minimal penalty)... but I think this is probably still the right way forward. It won't eliminate as much garbage, but it should leave garbage at worst linear in number of columns and independent of _size_ of columns, and mostly short lived. Which is probably good enough, and it is definitely more sane in scope. > Slightly More Off-Heap Memtables > -------------------------------- > > Key: CASSANDRA-6694 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6694 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Benedict > Assignee: Benedict > Labels: performance > Fix For: 2.1 beta2 > > > The Off Heap memtables introduced in CASSANDRA-6689 don't go far enough, as > the on-heap overhead is still very large. It should not be tremendously > difficult to extend these changes so that we allocate entire Cells off-heap, > instead of multiple BBs per Cell (with all their associated overhead). > The goal (if possible) is to reach an overhead of 16-bytes per Cell (plus 4-6 > bytes per cell on average for the btree overhead, for a total overhead of > around 20-22 bytes). This translates to 8-byte object overhead, 4-byte > address (we will do alignment tricks like the VM to allow us to address a > reasonably large memory space, although this trick is unlikely to last us > forever, at which point we will have to bite the bullet and accept a 24-byte > per cell overhead), and 4-byte object reference for maintaining our internal > list of allocations, which is unfortunately necessary since we cannot safely > (and cheaply) walk the object graph we allocate otherwise, which is necessary > for (allocation-) compaction and pointer rewriting. > The ugliest thing here is going to be implementing the various CellName > instances so that they may be backed by native memory OR heap memory. -- This message was sent by Atlassian JIRA (v6.1.5#6160)