Skip to content

Conversation

@netudima
Copy link
Contributor

Avoid BTree iterators allocation in ColumnsCollector.update
reduce amount of virtual calls for Cell.dataSize
avoid capturing lambda allocation in BTreeRow.clone
do not recalculate minLocalDeletionTime when BTreeRow is cloned

Patch by Dmitry Konstantinov; reviewed by TBD for CASSANDRA-21088

Avoid BTree iterators allocation in ColumnsCollector.update
reduce amout of virtual calls for Cell.dataSize
avoid capturing lambda allocation in BTreeRow.clone
do not recalculate minLocalDeletionTime when BTreeRow is cloned

Patch by Dmitry Konstantinov; reviewed by TBD for CASSANDRA-21088
BTree.apply(columns, function);
}

public <V> void apply(BiConsumer<V, ColumnMetadata> function, V argument)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is identical to other method public void apply(Consumer<ColumnMetadata> function), does passing the argument improves the performance and do you have any metrics to support that?

Copy link
Contributor Author

@netudima netudima Dec 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the idea was to avoid BTree iterator allocation AbstractMemtable.ColumnsCollector#update(org.apache.cassandra.db.RegularAndStaticColumns) using the apply method logic. At the same time I worried about introducing a capturing lambda as an extra allocation.

But, I've decided to re-check if a non-static method reference works as a capturing lambda and apparently it is not, I do not see an allocation in profiles if I use a method reference. So, I can just use the existing apply method without an extra argument and introducing of apply with an argument is not needed to solve the current issue.

return result;
}

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method & transformLeaf is duplicating a lot of code. Do we have any metrics on performance improvements? otherwise the duplication could cause cause inconsistencies in code, maintenance issues and could create bugs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I've attached test results to the ticket. Unfortunately the method reference trick which I mentioned in another comment does not work for logic in org.apache.cassandra.db.rows.BTreeRow#clone.
BTree functionality is stable and does not change frequently to introduce too much maintenance cost here. Also, the same pattern has been already used previously in this class for transformAndFilter logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants