Open brody4hire opened 1 month ago
I think I just misclassified this, this isn't exposed to the user.
foldhash
is the new default hasher from hashbrown
, it may also be worth considering.
I think the default hashbrown hasher is a very sensible default.
https://github.com/xacrimon/dashmap - found this in my GitHub recommendations FWIW
As discussed for changes proposed in #6938 - https://github.com/gfx-rs/wgpu/pull/6938#discussion_r1924595463: this project has been using some kind of "fast" hasher from
rustc-hash
v1, which we are now planning to use withhashbrown
, and I have identified some other possible hashers to recommend evaluating:ahash
- used byegui
nohash-hasher
- also used byegui
rustc-hash
v2 - ??? - I found some resources worth checking out: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: #6826P.S. I found some older context here, which I would like to comment on:
3369 / PR #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?