[
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:07 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.
The current change is simple, so the backport risks are small and the main
question is about a benefit. 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/pause/hardware
usage 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? (from
throughput/latency/pause/hardware usage point of view)
> 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]
