Dmitry Konstantinov created CASSANDRA-21524:
-----------------------------------------------

             Summary: 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


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]

Reply via email to