Skip to content

Reconsider Choice of HashMap Hasher #6999

Open
@brody4hire

Description

@brody4hire

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:

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 from rustc-hash. I think it was 100% 200% correct to drop use of the old fxhash in favor of rustc-hash. My one issue with rustc-hash is that it seems to contain both FxHasher, which can be used with hashbrown, and FxHashMap / FxHashSet typedefs which are hard-coded to using std::collections. So moving forward, we should use rustc_hash::FxHasher but not rustc_hash::FxHashMap or rustc_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

No one assigned

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions