[
https://issues.apache.org/jira/browse/CASSANDRA-21528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18103318#comment-18103318
]
Dmitry Konstantinov edited comment on CASSANDRA-21528 at 8/10/26 9:00 AM:
--------------------------------------------------------------------------
Hi [~taejin] , usually we only apply bug fixes to the 5.0.x branch. We can
consider some simple, minor improvements if they are safe and provide
significant value.
Do you have any end-to-end test results or profiles showing that backporting
these minor changes makes a visible difference for a real-world workload? (from
throughput/latency point of view)
was (Author: dnk):
Hi [~taejin] , usually we only apply bug fixes to the 5.0.x branch. We can
consider some simple, minor improvements if they are safe and provide
significant value.
Do you have any end-to-end test results or profiles showing that backporting
these minor changes makes a visible difference for a real-world workload?
> 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]
