compare compiler performance with `hashbrown`

[nikomatsakis]

This https://github.com/Amanieu/hashbrown crate looks nice!

We should do a performance comparison.

cc @Amanieu

[Amanieu]

This comes at the cost of only storing 7 bits of the hash (you still need one bit for empty/full). So in theory we could avoid rehashing up to a capacity of 128, but past that we need to rehash to retrieve the higher bits.

The 7 bits stored in the table are taken from the top bits of the hash code, while the bits used to determine the initial search position in the array are taken from the bottom bits. This is important since it means that when we find a matching control byte in the table, we have actually matched both the top and bottom bits of the hash code, which significantly decreases the chance of false positives.

However this means that these 7 bits are completely useless when rehashing, since they don't contain the bits used for determining the position in the array.

[Gankra]

Ah dang, well in my defense I haven't gotten to that part of the code review yet :)

[michaelwoerister]

Ah, interesting. Thanks for the info!

[mominul]

When will be the new HashMap implementation(hashbrown) stabilized?

[lnicola]

@mominul On July 4th, in 1.36, if I recall correctly.

[Gankra]

Closing: performance was explored, it was excellent, it is now the implementation of std::collections::HashMap (and Set).