-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
(tokio-util JoinMap) Remove raw-entry feature in favour of HashTable API. #7252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(tokio-util JoinMap) Remove raw-entry feature in favour of HashTable API. #7252
Conversation
let hash_builder = self.hashes_by_task.hasher(); | ||
self.tasks_by_key | ||
.shrink_to_fit(|(k, _)| hash_one(hash_builder, k)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. Why is hashes_by_task
needed inside tasks_by_key
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only need the hasher inside hashes_by_task
. It saves us from having to store a separate instance of the hasher.
An alternative solution could be to have a separate hasher: S
, and then make the HashMap<Id, u64>
use a cheaper hash function like a simple fibonacci hash (so no state is needed). That might be overkill though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference: conradludgate@5086eeb
170b7a9
to
6d238e2
Compare
6d238e2
to
bc16256
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks.
Co-authored-by: Alice Ryhl <[email protected]>
Motivation
While rebasing #7075, I noticed the change from #7219 which updates hashbrown, requiring the addition of the
raw-entry
feature. That inspired me to take a look at the actual JoinMap impl and I thought it could be improved by usingHashTable
instead.Solution
Replacing the
tasks_by_key
map with aHashTable
, we unlock a few benefits:tasks_by_key
, since we can fetch the ID from theAbortHandle
.S: BuildHasher
, as we are in-control over the hash-function, we can fetch the existing hasher fromhashes_by_task
.However, removing the ID from
tasks_by_key
will slow down those lookups (only injoin_next()
), as they now need a vtable lookup, rather than comparing against the id already in the current cache line.I don't feel strongly about this PR, I'm just quite fond of the HashTable API and thought I'd try it here.