[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838802#comment-13838802
]
Benedict commented on CASSANDRA-5549:
-------------------------------------
For a given run of the JVM the overhead is constant for each type of object
allocated, and the objects allocated can be predicted accurately given the
number of columns we are storing. I've done object size measurement before :-)
I don't see anything in CASSANDRA-4860 that is surprising, but perhaps I've
missed something specific you're worrying about? In general it's dealing with
"miscalculating" the portion of a ByteBuffer we're referencing. This is a
concern for live bytes, not retained bytes, and my scheme outlined above was
for retained bytes which is what we care about for memory constraints, but I
will also be replacing the live bytes calculation, since it will be easy to do
at the same time. But the same approach works, care is just needed.
> Remove Table.switchLock
> -----------------------
>
> Key: CASSANDRA-5549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Labels: performance
> Fix For: 2.1
>
> Attachments: 5549-removed-switchlock.png, 5549-sunnyvale.png
>
>
> As discussed in CASSANDRA-5422, Table.switchLock is a bottleneck on the write
> path. ReentrantReadWriteLock is not lightweight, even if there is no
> contention per se between readers and writers of the lock (in Cassandra,
> memtable updates and switches).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
