Open
Description
As discussed for changes proposed in #6938 - #6938 (comment): this project has been using some kind of "fast" hasher from rustc-hash
v1, which we are now planning to use with hashbrown
, and I have identified some other possible hashers to recommend evaluating:
ahash
- used byegui
nohash-hasher
- also used byegui
- consider using hasher from
rustc-hash
v2 - ??? - I found some resources worth checking out:- Replace hash with faster and better finalized hash rust-lang/rustc-hash#37
- https://nnethercote.github.io/2021/12/08/a-brutally-effective-hash-function-in-rust.html
- https://www.reddit.com/r/rust/comments/rbe3vn/a_brutally_effective_hash_function_in_rust/ - contains some very interesting discussion & comparisons with other hashers
- https://www.reddit.com/r/rust/comments/1div5vh/rustchash_20/
- I noticed more hashers listed in: https://github.com/RustCrypto/hashes
This kind of decision should be backed up with some benchmark testing.
Context: PR #6938 is part of some preparation I am contributing for no-std
support, as requested in: #6826
P.S. I found some older context here, which I would like to comment on:
- Both fxhash and rustc-hash are in the dependency tree #3369 / PR Replace fxhash with rustc-hash #3502 - it looks to me like the old
fxhash
crate was some kind of copy of the hasher fromrustc-hash
. I think it was100%200% correct to drop use of the oldfxhash
in favor ofrustc-hash
. My one issue withrustc-hash
is that it seems to contain bothFxHasher
, which can be used withhashbrown
, andFxHashMap
/FxHashSet
typedefs which are hard-coded to usingstd::collections
. So moving forward, we should userustc_hash::FxHasher
but notrustc_hash::FxHashMap
orrustc_hash::FxHashSet
.
P.S. 2: Considering that this could affect API, as Fitzgerald noted with the label, I start to wonder if this could have serious impact on any external users?
Metadata
Metadata
Assignees
Type
Projects
Status
Todo