Compute 64-bit Xor in place - #565
Open
gitRasheed wants to merge 3 commits into
Open
Conversation
1 task
An array or run receiver XORed with a bitmap container ran the in-place operation on the argument's container and adopted it, so a.Xor(b) changed b and left both bitmaps sharing storage. Compute the result on the receiver's side instead. The test covers every in-place operation and container pair.
Keys present only in the argument were inserted by pointer, so editing the receiver afterwards changed the argument. Clone them, as Or does. XORing a bitmap with itself removed entries from the structure being iterated and could panic; clear the receiver instead, as the 32-bit Xor does.
Reuse the receiver's writable container instead of allocating a fresh symmetric difference for every matching key.
gitRasheed
force-pushed
the
perf/xor64-inplace
branch
from
September 5, 2026 21:33
dcb6378 to
345acd1
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
1 participant
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.
Description
Includes the two commits of #564, which this change needs: the in-place path calls the 32-bit
Xor, and before that fix it modifies its argument. The diff reduces to one commit once #564 merges.roaring64.Bitmap.Xorallocated a fresh symmetric difference for every matching key and swapped it into the receiver. It now XORs into the receiver's writable container, as the 32-bitXordoes. Unshared dense containers stop allocating.Type of Change
Changes Made
What was changed?
roaring64/roaring64.go:getWritableContainerAtIndexplus the 32-bit in-placeXor, replacingroaring.Xor.roaring64/xor_inplace_test.go: zero allocations on dense reuse, and benchmarks.Why was it changed?
It was the only in-place set operation here that still allocated the result for every matching key.
How was it changed?
Two lines.
Testing
go test ./...passes on arm64 and amd64. The ownership test from #564 covers every container pair.Formatting
go fmtclean.Performance Impact
Against #564 on c8g.xlarge, medians of ten one-second samples on one pinned core, benchstat p < 0.001 unless marked. Each synthetic input has four keys. A reuse op is two XORs that restore the receiver; a clone-and-xor op is one clone and one XOR. Each real-data op clones the left bitmap and XORs it with the right for all 199 adjacent pairs of the dataset, lifted to one 64-bit prefix so the keys match.
After RunOptimize the three datasets improve by 6%, 26% and 8%.
Breaking Changes
None.