[
https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742700#comment-14742700
]
Ariel Weisberg commented on CASSANDRA-9738:
-------------------------------------------
OK, well I don't have an answer for 3.0 on how to completely eliminate the risk
that the copying overhead won't be an issue.
If it keeps changing there is no way I will get to the point where I can +1 the
performance dimension. I might be able to get to +1 correctness if things stop
changing long enough for me to checkout it out and walk through everything.
Performance could very well be good enough/better for realistically sized
indexed entries. If we benchmark the final code and it's better then I guess I
could be +1 on performance and ignore the overhead of allocating and copying
for each cache access.
In hindsight wholesale replacing the existing key cache was not a good
incremental way to effect this change in a low risk way. Introducing a new key
cache and iterating on it would have allowed for faster development, more
frequent merging to trunk, smaller reviews etc. We would also always have
something to ship once release time rolls around even if something change was
pending.
* [IndexEntryStats, I don't get why you are casting down to int, why not
checked cast on the way
out?|https://github.com/apache/cassandra/commit/5d53c29ceb915b1b95bca0fff15b1591d508e8c8#diff-75146ba408a51071a0b19ffdfbb2bb3cR1434]
* [I don't understand overflow protection here. It's a long is it really going
to
overflow?|https://github.com/apache/cassandra/commit/5d53c29ceb915b1b95bca0fff15b1591d508e8c8#diff-75146ba408a51071a0b19ffdfbb2bb3cR1434]
* Average not taking into account the distribution is suspect to me. Should the
allocation be slightly larger than average to prevent reallocation?
* When allocating the offset buffer it's using the count of index infos without
multiplying by their size?
* We are writing sampled records. I am skeptical this is worth optimizing when
we have to get this done and correct. There are better options in subsequent
versions like appending to a file.
* Did this change have an impact and improve some metric?
> 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.0 rc1
>
>
> 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)
