You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Michael Semb Wever (Jira)" <ji...@apache.org> on 2026/09/13 07:44:00 UTC

[jira] [Updated] (CASSANDRA-21524) Row merging logic optimizations

     [ https://issues.apache.org/jira/browse/CASSANDRA-21524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Semb Wever updated CASSANDRA-21524:
-------------------------------------------
    Fix Version/s: 6.0-alpha3
                       (was: 6.0-alpha2)

> Row merging logic optimizations
> -------------------------------
>
>                 Key: CASSANDRA-21524
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21524
>             Project: Apache Cassandra
>          Issue Type: Improvement
>          Components: Local/Other
>            Reporter: Dmitry Konstantinov
>            Assignee: Dmitry Konstantinov
>            Priority: Normal
>             Fix For: 6.0, 6.0-alpha3, 7.0
>
>         Attachments: CASSANDRA-21524-6.0_ci_summary.htm, CASSANDRA-21524-6.0_results_details.tar.xz, CASSANDRA-21524-trunk_ci_summary.htm, CASSANDRA-21524-trunk_results_details.tar.xz, cpu_merger_after.png, cpu_merger_before.png, jul15_merge_check_after_cpu.html, jul15_merge_check_before_cpu.html
>
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The ticket is focused on CPU tuning of row merging logic under Row$Merger.merge used during reads (and not only).
> * there is no need to add empty interators to columnDataIterators if a row is null, also 2 loops over rows can be combined into one
> * MergeIterator logic is generic and can be used in many different use cases, for example to merge partitions and merge rows. While it is useful from development point of view to avoid duplicated code - it is non-friendly for JIT, we have polluted profiles with more that 2 types per call site, so we pay for it with frequent metamorphic calls, it is especially costly when we iterate over cells. A possible way to avoid this issue is to copy the class during a build time to create a separate class with exactly the same code but a different name. It allows to avoid  development overheads with duplicated code to edit and at the same time helps JIT to optimize.
> * When we created a merged row we need to calculated minDeletionTime. If none of the merged rows had any deletion or expiring data, neither does the result, so we can pass the already-known min local deletion time and avoid rescanning the whole btree to recompute it.
> * DeletionTime.deletes check can skip Cell.timestamp invocation (potentially megamorphic) if the DeletionTime is LIVE.
> * In most cases merged cells have identical types, so we can add a fast path for it to Row.Merger.ColumnDataReducer#useColumnMetadata
> * ColumnDataReducer.versions can be switched from List to array to reduce allocations and to avoid extra deferences and checks/conditions.
> * replaceAndSink is large but we can split it to hot and colder parts to allow it to inline hot part into reduce method



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org