[ 
https://issues.apache.org/jira/browse/CASSANDRA-20428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934322#comment-17934322
 ] 

Dmitry Konstantinov commented on CASSANDRA-20428:
-------------------------------------------------

I think (I am happy to be wrong :-)) fully eliminate these allocations along 
all paths is really hard. At the same time for compaction logic I suppose it is 
doable (taking in account that it is happening locally within a single thread 
which simplifies buffers re-usage for it).
There was a similar discussion about this area in CASSANDRA-15393

> 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]

Reply via email to