[
https://issues.apache.org/jira/browse/CASSANDRA-15393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185886#comment-17185886
]
Caleb Rackliffe commented on CASSANDRA-15393:
---------------------------------------------
{quote}The 4.0.x line is going to be around for a while…
{quote}
{quote}that's not an argument in itself to waiver this patch into 4.0-beta, and
sets the precedence for feature creep
{quote}
That was an argument for making an incremental change now rather than waiting
for hard Java 11 support/varargs/etc., not necessarily an argument for this
being in 4.0-beta.
{quote}I would definitely vote for the incremental approach, but starting in
4.0.x
{quote}
Is there's a big difference between allowing performance improvements,
especially ones that address real operational problems, into {{beta}} vs.
{{4.0.x?}} If anything, allowing it into the former would mean we find problems
earlier. (Assuming there is a statutory prohibition on this kind of thing at
this point, I suppose that means I'm arguing for a waiver...)
> Add byte array backed cells
> ---------------------------
>
> Key: CASSANDRA-15393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15393
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Compaction
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We currently materialize all values as on heap byte buffers. Byte buffers
> have a fairly high overhead given how frequently they’re used, and on the
> compaction and local read path we don’t do anything that needs them. Use of
> byte buffer methods only happens on the coordinator. Using cells that are
> backed by byte arrays instead in these situations reduces compaction and read
> garbage up to 22% in many cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
