[
https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709670#comment-14709670
]
Ariel Weisberg commented on CASSANDRA-9738:
-------------------------------------------
For reading a string there is no reason not to use the last bit and allow
strings 65k strings. It also doesn't throw if the length is too large.
I really would like to get to the one true string reading/writing path if
possible. So we can put together one good implementation and also to optimize
icache. To allocate or pool temporary buffers is kind of a question of how
allocation bound you are. I think the answer for C* right now is very.
Is it feasible to share the same pooling buffer for both the key serialization
and value serialization? Maybe a little finicky given that size is sometimes
retrieved in an order that is different from the order they are serialized in.
> Migrate key-cache to be fully off-heap
> --------------------------------------
>
> Key: CASSANDRA-9738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.0 beta 2
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and
> feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure
> off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some
> benefit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
