[
https://issues.apache.org/jira/browse/CASSANDRA-21524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096862#comment-18096862
]
Dmitry Konstantinov commented on CASSANDRA-21524:
-------------------------------------------------
Added MergeIterator code copy for UnfilteredRowIterators too:
{code}
Results:
Op rate : 183,139 op/s [partition-select: 183,139 op/s]
Partition rate : 182,186 pk/s [partition-select: 182,186 pk/s]
Row rate : 1,821,862 row/s [partition-select: 1,821,862 row/s]
Latency mean : 1.6 ms [partition-select: 1.6 ms]
Latency median : 0.9 ms [partition-select: 0.9 ms]
Latency 95th percentile : 2.9 ms [partition-select: 2.9 ms]
Latency 99th percentile : 15.4 ms [partition-select: 15.4 ms]
Latency 99.9th percentile : 26.8 ms [partition-select: 26.8 ms]
Latency max : 137.4 ms [partition-select: 137.4 ms]
Total partitions : 14,921,973 [partition-select: 14,921,973]
Total errors : 0 [partition-select: 0]
Total GC count : 19
Total GC memory : 350.607 GiB
Total GC time : 0.3 seconds
Avg GC time : 17.2 ms
StdDev GC time : 0.7 ms
Total operation time : 00:01:21
{code}
> 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.x, 7.x
>
> Attachments: cpu_merger_after.png, cpu_merger_before.png,
> jul15_merge_check_after_cpu.html, jul15_merge_check_before_cpu.html
>
> Time Spent: 10m
> 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: [email protected]
For additional commands, e-mail: [email protected]
