Avoid rewriting the parent tree when removing an absent subtree value#1295
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1295 +/- ##
=======================================
Coverage 90.21% 90.22%
=======================================
Files 36 36
Lines 16289 16320 +31
=======================================
+ Hits 14695 14724 +29
- Misses 1594 1596 +2
🚀 New features to boost your workflow:
|
MultimapTable::remove() computed whether the value existed in the subtree but then ran the re-insert block unconditionally. When the value was not present, subtree.remove() returned None and left the subtree untouched, yet the collection was still re-inserted into the parent tree. That copy-on-wrote the root->leaf path, queued the old pages to be freed, and could even flip the value-set from subtree back to inline storage -- all for a logical no-op. The inline arm and Table::remove() already short-circuit correctly. Return early when the value was not present, matching the inline arm. Contents, length, and integrity were already unaffected; this only removes the wasted write amplification. Add a regression test that asserts a no-op remove on a subtree-backed key allocates and frees no pages. Assisted-by: Claude Code Claude-Session: https://claude.ai/code/session_01AHrwK7untocWhi8S4VV9V2 Assisted-by: Claude
1345c63 to
caf2f37
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MultimapTable::remove()computed whether the value existed in the subtree but then ran its re-insert block unconditionally. When the removed value was not present,subtree.remove()returnedNoneand left the subtree untouched (delete_keyleaves the root untouched when the key isn't found), yet the collection was still re-inserted into the parent tree. That copy-on-wrote the root→leaf path, queued the old pages to be freed, and could even flip the value-set from subtree back to inline storage — all for a logical no-op. The inline arm andTable::remove()already short-circuit correctly.The fix returns early when the value was not present, matching the inline arm.
Impact
Contents, length, and integrity were already unaffected — this only removes the wasted write amplification for a common operation (removing a value that isn't present from a subtree-backed key).
Testing
multimap_remove_nonexistent_value_from_subtree_does_not_churnasserts that a no-op removal on a subtree-backed key allocates and frees zero pages. It fails before the fix (baseline 7 → 10 allocated pages from the transient CoW churn) and passes after.cargo fmt --check,cargo clippy --all-targets --all-features, andcargo test --all-features(310 tests, 0 failures).🤖 Generated with Claude Code
https://claude.ai/code/session_01AHrwK7untocWhi8S4VV9V2
Generated by Claude Code