[
https://issues.apache.org/jira/browse/CASSANDRA-20428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934615#comment-17934615
]
David Capwell commented on CASSANDRA-20428:
-------------------------------------------
When I first joined this project I did a POC that fetched a "allocator" from a
thread local and would call that for allocating rather than directly allocating
in AbstractType.read, this drastically lowed memory but required that the
caller now has to "release" everything, and I then got distracted by repair
work and moved away...
Removing the allocating was easy, but that just shifts the problem to managing
the allocation, which is larger work. For compaction and repair this is a good
idea as it would be easy enough to release at each row/partition so we can have
very limited memory
bq. Eliminate byte array allocation in ByteArrayAccessor.read
I personally would rephrase this to "Eliminate byte array allocation in
AbstractType.read", as that is actually what matters?
> Eliminate byte array allocation in ByteArrayAccessor.read
> ---------------------------------------------------------
>
> Key: CASSANDRA-20428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20428
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Jon Haddad
> Priority: Normal
> Attachments: allocation-reverse.html,
> image-2025-03-11-11-05-55-378.png
>
>
> During compaction we allocate a new byte[] in ByteArrayAccessor.read. This
> is one of the hottest paths in the codebase, hit during writes, compaction,
> creating tables, and possibly others. In my performance tests using default
> compaction settings of 64MB I see this responsible for 40% of allocations.
> This is largely what drives GC pause frequency and duration. If we are able
> to eliminate the O(N) allocations performed here, this might be one of the
> best optimizations we could do for the number of things it touches.
> Allocation profile attached.
> !image-2025-03-11-11-05-55-378.png|width=514,height=269!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
