Reduce arena allocations when materializing RocksDB range read results#13273
Open
pchintar wants to merge 2 commits into
Open
Reduce arena allocations when materializing RocksDB range read results#13273pchintar wants to merge 2 commits into
pchintar wants to merge 2 commits into
Conversation
saintstack
reviewed
May 29, 2026
Contributor
saintstack
left a comment
There was a problem hiding this comment.
Looking good. I think needs formatting?
| : KeyValueRef(a, copyFrom.key, copyFrom.value) {} | ||
|
|
||
| bool operator==(const KeyValueRef& r) const { return key == r.key && value == r.value; } | ||
| bool operator!=(const KeyValueRef& r) const { return key != r.key || value != r.value; } |
Contributor
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Contributor
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Contributor
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Contributor
Result of foundationdb-pr-clang on Linux RHEL 9
|
Contributor
Result of foundationdb-pr on Linux RHEL 9
|
Contributor
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
deb2168 to
3d0286d
Compare
Contributor
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Author
Hi @saintstack I just fixed all the formatting issues by using |
Contributor
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Contributor
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Contributor
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Contributor
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Contributor
Result of foundationdb-pr on Linux RHEL 9
|
Contributor
Result of foundationdb-pr-clang on Linux RHEL 9
|
Contributor
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
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.
Closes issue #13272
Summary
Reduce arena allocations when materializing RocksDB range read results.
Currently, every
KeyValueRefdeep-copy performs two independent arena allocations:This PR instead packs both payloads into a single contiguous arena allocation while preserving existing ownership and
StringRefsemantics.Changes
Current implementation:
This performs two separate
StringRef(Arena&, ...)allocations per returned KV pair.In contrast, my PR introduces a packed-copy path:
which:
KeyRef/ValueRefviews over the packed storage.The RocksDB range-read paths now use:
instead of constructing a temporary
KeyValueReffollowed by generic deep-copy construction.Overall this reduces arena allocation count from:
during range-result materialization.
No public APIs, wire formats, or ownership semantics are changed.
Testing
Note: A full benchmark comparison and large-scale simulation workload validation couldn't be performed locally due to my hardware limitations