[
https://issues.apache.org/jira/browse/CASSANDRA-21711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120385#comment-18120385
]
Dmitry Konstantinov commented on CASSANDRA-21711:
-------------------------------------------------
# We have several places in hot code path where we compare clustering keys, and
the classes of compared objects are different:
## Write path
### mutation creation: we need to sort incoming rows by clustering key in case
of a batch insert to form a BTree. We compare BufferClustering instances here
### memtable partition update: we merge incoming rows into the existing
BTree-based partition. We compare BufferClustering instances here with
memtable-type instances, for example in case of off-heap memtable - with
NativeClustering
### flushing: we calculate min/max clustering for sstable metadata, to do it
we compare memtable-type Clustering instances.
## Read path
### sstable/memtable data iterating: slicing required data based on a
selected clustering key. We compare ArrayClustering (deserialized rows) with
BufferClustering (from CQL level)
# JIT considers a call as megamorphic even if we have some rare scenario
executed for a call site, so we want to avoid polluting of hot call-sites with
incidentally coming values
There are 3 main strategy to deal with megamorphic calls:
* Reduce number of implementations. I do not see a simple option here as of
now, it is hard to replace BufferClustering in CQL code as of now, there are
too many dependencies to ByteBuffer, we also do not want to switch back to
BufferClustering for deserialized rows, it would increase allocation.
* Split call sites using if/switch: not free, makes code less readable
* Duplicate code to use different one in each scenario (hard to maintain in
case of a manual code duplication). As a a part of CASSANDRA-21524 a copy class
logic was introduced to duplicate code during a build time, so we do not
increase amount of developer-written code from one side and we split call sites
without conditional logic from another side.
So, in the current scenario the copy class logic looks the most attractive
option to try.
> Reduce megamorphic calls overhead in ClusteringComparator
> ---------------------------------------------------------
>
> Key: CASSANDRA-21711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21711
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 6.0.x, 7.x
>
> Attachments: example_cpu.html, image-2026-09-23-12-10-25-484.png
>
>
> I observe 4.58% of CPU consumed by ClusteringComparator logic for 10-row
> batch insert workload, large portion of it related to megamorphic calls
> !image-2026-09-23-12-10-25-484.png|width=600!
> flamegraph example: [^example_cpu.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
