Add additional benchmarks. #56
Merged
Conversation
This file contains 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
|
You've got some failures on the |
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Mar 31, 2019
56: Add additional benchmarks. r=Amanieu a=tkaitchuck This covers performance of three cases I wanted to study when looking into https://github.com/Amanieu/hashbrown/issues/48 They are: `grow_by_insertion_kb` which is similar to grow by insertion, but instead of every entry differing by 1, they differ by 1024. This makes an important performance difference to the hasher. `find_existing_high_bits` which is similar to find_existing but uses 64 bit keys instead of 32 bit keys, where the lower 32 bits are zeros. This is a pathologically bad case for FxHash. `insert_8_char_string` tests a case where the key is a string. (As opposed to all the existing tests which operate on u32 values. This is important to cover because strings as keys are very common. Co-authored-by: Tom Kaitchuck <tom.kaitchuck@dell.com>
Timed out |
|
@bors retry |
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Apr 13, 2019
56: Add additional benchmarks. r=Amanieu a=tkaitchuck This covers performance of three cases I wanted to study when looking into https://github.com/Amanieu/hashbrown/issues/48 They are: `grow_by_insertion_kb` which is similar to grow by insertion, but instead of every entry differing by 1, they differ by 1024. This makes an important performance difference to the hasher. `find_existing_high_bits` which is similar to find_existing but uses 64 bit keys instead of 32 bit keys, where the lower 32 bits are zeros. This is a pathologically bad case for FxHash. `insert_8_char_string` tests a case where the key is a string. (As opposed to all the existing tests which operate on u32 values. This is important to cover because strings as keys are very common. 62: Remove incorrect debug_assert r=Amanieu a=Amanieu Fixes #60 Co-authored-by: Tom Kaitchuck <tom.kaitchuck@dell.com> Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
Build succeeded
|
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 covers performance of three cases I wanted to study when looking into https://github.com/Amanieu/hashbrown/issues/48
They are:
grow_by_insertion_kbwhich is similar to grow by insertion, but instead of every entry differing by 1, they differ by 1024. This makes an important performance difference to the hasher.find_existing_high_bitswhich is similar to find_existing but uses 64 bit keys instead of 32 bit keys, where the lower 32 bits are zeros. This is a pathologically bad case for FxHash.insert_8_char_stringtests a case where the key is a string. (As opposed to all the existing tests which operate on u32 values. This is important to cover because strings as keys are very common.