[CASSANDRA-20129] Restore optimization in MultiCBuilder around building one clustering

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 5.1
• Component/s: Legacy/Local Write-Read Paths
• Bug Category: Degradation - Performance Bug/Regression
• Severity: Normal
• Complexity: Normal
• Discovered By: Performance Regression Test
• Platform: All
• Since Version: 5.1

Source Control Link

https://github.com/apache/cassandra/commit/ce035b021542717a61972a00fe341d9ac9f829d3

Test and Documentation Plan

There should be no implications for correctness here. Once we pass the existing test suite, the main concern is that we avoid BTree builder and iterator creations in MultiCBuilder#build().

• Assignee: Caleb Rackliffe
• Reporter: Caleb Rackliffe

Authors

Caleb Rackliffe

Reviewers

Abe Ratnofsky, Benjamin Lerer, Bernardo Botella

• Created: 06/Dec/24 20:44
• Updated: 11/Dec/24 17:56
• Resolved: 11/Dec/24 03:08

Description

Back in CASSANDRA-10409, we optimized the single clustering case for MultiCBuilder to produce less garbage. In CASSANDRA-19341, we de-facto removed that optimization, and I'm seeing increased allocations in trunk, specifically at least double the number of BTree builders. In the write-heavy workload I'm profiling, this jumps up to become the most common TLAB allocation. I'm attaching JFR screenshots from 4.1 and trunk that show the codepaths that touch this on both versions. We should consider reintroducing something like the old OneClusteringBuilder.

I used WriteBench to explore things here, mostly w/ the TRUNCATE EndOp, and made sure commitlog writes, view updates, and CassandraTableWriteHandler tracing were disabled to reduce the noise.

blerer

Issue Links

• relates to: CASSANDRA-19341 Relation and Restriction hierarchies are too complex and error prone
• links to: GitHub Pull Request #3735