Use hashbrown::HashTable instead of RawTable
#343
Conversation
|
I previously considered this in #280, and it didn't seem beneficial at the time, but now On the idea of forking -- I wonder if much could be gained by hard-coding that we always use |
I tested this in rustc, but it didn't show any noticeable change in compiler performance: rust-lang/rust#129965 |
|
Just popping in to say that since I'm going to be working a lot on moving over The raw table API is very messy and was designed before |
| /// When using `HashTable::find_entry`, that takes hold of `&mut indices`, so we have to borrow our | ||
| /// `&mut entries` separately, and there's no way to go back to a `&mut IndexMapCore`. So this type |
There was a problem hiding this comment.
@clarfonthey Just to highlight, this comment is the part that I find most unfortunate about the change: it makes our OccupiedEntry larger to carry separate &mut references, and also makes the core methods more awkward to call from the entry. This new RefMut recovers some of the ergonomics, but I don't know that it's possible to avoid the size increase at all.
Before, raw::Bucket allowed me to store that with the full &mut IndexMapCore in the entry.
There was a problem hiding this comment.
Hmm, yeah, I should add that one thing I definitely want to improve is all of the wasted space in a lot of the internal types.
cuviper
force-pushed
the
hash_table
branch
2 times, most recently
from
5b4a7a6
to
ad4af01
Compare
Test indexmap#343 - using hashbrown 0.15 with HashTable In indexmap-rs/indexmap#343, I've ported to hashbrown 0.15, which also requires a change from `RawTable` (now private) to `HashTable`. This PR is patching to use that unpublished branch so I can test rustc performance. r? ghost
No description provided.