[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908336#comment-13908336
]
Sylvain Lebresne commented on CASSANDRA-6694:
---------------------------------------------
I know I'll sound like a killjoy, but quickly skimming over the patch, this is
a big patch that moves a lot of code, and more importantly to me, seems to add
a lot of clutter in places that a priori don't seem all that much related
(everywhere in the CQL3 code typically). I'm not saying that such changes
aren't necessary, nor really criticizing the approach (I certainly haven't look
at the patch close enough for that), just remarking that this is a lot of
changes, and, it seems to me, a non negligible amount of added clutter.
With that in mind, I don't necessary have a problem with this change in theory
if such change has demonstrable non-negligible positive impact on performance,
but I do have 2 small "worries":
# I do would want to see tests that demonstrable the non-negligible positive
impact on performance before committing such change, not *just* tests that show
this doesn't degrade performance. This might be the intent of everyone and I
might just be stating the obvious, and my apologies for the distraction if
that's the case, but the comments above seems to mainly mention the "check it
doesn't degrade things" part, and so I just want to make sure we're on the same
page. Are we?
# this is marked for 2.1-beta2. Is it really reasonable to target big (and
rather intrusive) changes like that for 2.1 at this point? Does that really
give us the proper time to review such changes and evaluate the gains it give
use before committing it?
> 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)
