Switch hashmap implementation to open addressing #301
Conversation
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
jserv
reviewed
Sep 12, 2025
jserv
reviewed
Sep 12, 2025
visitorckw
suggested changes
Sep 12, 2025
There was a problem hiding this comment.
I noticed the PR description includes some performance numbers, which is great. However, the commit message only vaguely mentions "slightly higher memory usage" and "significantly improved execution time." Could you include the actual measurements in the commit message as well?
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 2 files
Prompt for AI agents (all 1 issues)
Understand the root cause of the following 1 issues and fix them.
<file name="src/defs.h">
<violation number="1" location="src/defs.h:103">
The new open addressing implementation is fragile because it lacks a 'DELETED' state (tombstone). If an entry is ever removed by setting its state to 0 ('empty'), it will break lookups for all subsequent entries in the same collision chain.</violation>
</file>
Since this is your first cubic review, here's how it works:
- cubic automatically reviews your code and comments on bugs and improvements
- Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
- Ask questions if you need clarification on any suggestion
React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.
visitorckw
reviewed
Sep 12, 2025
icgmilk
force-pushed
the
fix_hashmap
branch
from
4d3545d to
c948a44
Compare
visitorckw
reviewed
Sep 12, 2025
visitorckw
reviewed
Sep 12, 2025
visitorckw
reviewed
Sep 12, 2025
visitorckw
reviewed
Sep 12, 2025
jserv
reviewed
Sep 12, 2025
icgmilk
force-pushed
the
fix_hashmap
branch
from
c948a44 to
bf383cf
Compare
Replace chaining with open addressing using Linear Probing. Set load factor to 50% to balance probe length and performance. This change trades ~320 kB of memory for ~30 ms faster execution, primarily due to better cache locality.
icgmilk
force-pushed
the
fix_hashmap
branch
from
bf383cf to
f513a1c
Compare
jserv
requested changes
Sep 12, 2025
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.
This PR replaces chaining with open addressing using linear probing. Set load factor to 50% to balance probe length and performance.
This change trades ~320 kB of memory for ~30 ms faster execution, primarily due to better cache locality.
Performance analysis for out/shecc src/main.c
Using
/usr/bin/time -vand uftrace to benchmark memory usage and execution time.Chaining
/usr/bin/time -vuftrace
Open Addressing
/usr/bin/time -vuftrace
Summary by cubic
Switch hashmap from separate chaining to open addressing with linear probing, rehashing at 50% load. This improves cache locality and delivers a small, consistent speedup with similar memory usage.
Refactors
Performance