Do some cleanups for hashmaps #45263
Merged
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
kennytm
added
the
S-waiting-on-review
|
@arthurprs is probably interested in this PR |
arthurprs
approved these changes
Oct 14, 2017
src/libstd/collections/hash/table.rs
Outdated
| @@ -768,7 +767,7 @@ impl<K, V> RawTable<K, V> { | |||
| // This is great in theory, but in practice getting the alignment | |||
| // right is a little subtle. Therefore, calculating offsets has been | |||
| // factored out into a different function. | |||
| let (alignment, hash_offset, size, oflo) = calculate_allocation(hashes_size, | |||
| let (alignment, size, oflo) = calculate_allocation(hashes_size, | |||
| align_of::<HashUint>(), | |||
There was a problem hiding this comment.
Nit: lines bellow need some formating adjustments.
| @@ -1157,6 +1156,7 @@ impl<K: Clone, V: Clone> Clone for RawTable<K, V> { | |||
| } | |||
|
|
|||
| new_ht.size = self.size(); | |||
| new_ht.set_tag(self.tag()); | |||
There was a problem hiding this comment.
Good point, I overlooked that before.
kennytm
added
S-waiting-on-author
Manishearth
force-pushed
the
hashmap-clean
branch
from
fb187f8 to
85bc99e
Compare
|
Fixed |
Manishearth
force-pushed
the
hashmap-clean
branch
from
85bc99e to
9d70129
Compare
This offset is always zero, and we don't consistently take it into account. This is okay, because it's zero, but if it ever changes we're going to have bugs (e.g. in the `dealloc` call, where we don't take it into account). It's better to remove this for now; if we ever have a need for a nonzero offset we can add it back, and handle it properly when we do so.
This isn't strictly necessary for hashmap cloning to work. The tag is used to hint for an upcoming resize, so it's good to copy this information over. (We can do cleverer things like actually resizing the hashmap when we see the tag, or even cleaning up the entry order, but this requires more thought and might not be worth it)
Manishearth
force-pushed
the
hashmap-clean
branch
from
9d70129 to
e8e7715
Compare
|
@bors r+ rollup Thanks @Manishearth and @arthurprs |
|
📌 Commit e8e7715 has been approved by |
kennytm
added
S-waiting-on-bors
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Oct 14, 2017
Do some cleanups for hashmaps @mystor noticed some things whilst reading through the hashmap RawTable code. Firstly, in RawTable we deal with this hash_offset value that is the offset of the list of hashes from the buffer start. This is always zero, and this isn't consistently used (which means that we would have bugs if we set it to something else). We should just remove this since it doesn't help us at all. Secondly, the probing length tag is not copied when cloning a raw table. This is minor and basically means we do a bit more work than we need on further inserts on a cloned hashmap. r? @gankro
bors
added a commit
that referenced
this pull request
Oct 14, 2017
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Oct 15, 2017
Do some cleanups for hashmaps @mystor noticed some things whilst reading through the hashmap RawTable code. Firstly, in RawTable we deal with this hash_offset value that is the offset of the list of hashes from the buffer start. This is always zero, and this isn't consistently used (which means that we would have bugs if we set it to something else). We should just remove this since it doesn't help us at all. Secondly, the probing length tag is not copied when cloning a raw table. This is minor and basically means we do a bit more work than we need on further inserts on a cloned hashmap. r? @gankro
bors
added a commit
that referenced
this pull request
Oct 15, 2017
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.
@mystor noticed some things whilst reading through the hashmap RawTable code.
Firstly, in RawTable we deal with this hash_offset value that is the offset of the list of hashes from the buffer start. This is always zero, and this isn't consistently used (which means that we would have bugs if we set it to something else). We should just remove this since it doesn't help us at all.
Secondly, the probing length tag is not copied when cloning a raw table. This is minor and basically means we do a bit more work than we need on further inserts on a cloned hashmap.
r? @gankro