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

koo commented on CASSANDRA-21528:
---------------------------------

[~dnk] 
We're running Cassandra 5.0.8 in production and are seeing resource pressure, 
so we'd really like to have this improvement available in a future 5.0.x 
release. Would it be okay for me to open a PR against the cassandra-5.0 branch?
 Also, while going through the patch, it looked like some of the tuning in 
there could be applied to 5.0.x as well. Would you be open to including those 
as part of the backport?

> Cache Enum.values() in ClusteringPrefix.Kind deserialization to avoid 
> per-read array allocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-21528
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21528
>             Project: Apache Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Core
>            Reporter: koo
>            Assignee: koo
>            Priority: Normal
>             Fix For: 6.0-alpha2, 7.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> *description* 
> When deserializing clusterings and range/slice bounds, the kind is resolved 
> via Kind.values()[in.readByte()]:                
>  -  ClusteringPrefix.java:616 — ClusteringPrefix.Deserializer (streaming 
> path) //  5.0.7
>       
> Enum.values() creates a new copy of its array every time it is called. So 
> each time we read a clustering or a bound, a new Kind[] array is created just 
> to look up one value by index, and then thrown away. This runs on the hot  
> deserialization path, so it creates a lot of short-lived garbage for no real 
> benefit.
>     
> Impact (measured, JFR allocation profiling on a read/Paxos-LWT-heavy 
> workload):           
>   - Total heap allocation observed: ~170 GB (120s)
>   - ClusteringPrefix$Kind[]: ~5.22 GB (≈3.1%) of that total 
> This garbage is short-lived, so GC pause impact under a modern collector is 
> minimal and CPU cost is negligible; this is purely an allocation-pressure / 
> GC-throughput improvement.                                                    
>              



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