Use XOR with shift for cache key calculation#413
Open
kelhusseiny wants to merge 1 commit intomainfrom
Open
Conversation
The previous XOR-based cache key computation was commutative, meaning swapped tag values would produce the same cache key. For example: (true, false) and (false, true) would both produce the same hash. This replaces XOR with rotate-left + XOR: - Rotation makes it order-dependent, preventing collisions when values swap - XOR keeps the result bounded, avoiding Bignum allocations The multiply-and-add approach (like Java's Objects.hash) was considered but causes Bignum allocations when hash values overflow during multiplication.
kelhusseiny
force-pushed
the
karim/fix-cache-key-collision
branch
from
14f550e to
969ad48
Compare
gmalette
approved these changes
Jan 29, 2026
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
2 participants
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
Changes the cache key calculation in CompiledMetric from rotate-left + XOR to XOR with position-based shifts.
Motivation
The previous implementation used a rotate-left + XOR approach which is more complex and slower. Benchmarking shows that XOR with shift achieves the same performance as plain XOR while maintaining order-dependency to prevent collisions when tag values are swapped.
Changes
Benchmark Results
XOR with shift is ~15% faster than rotation while maintaining the same collision-resistance properties.