More bangs

[Bodigrim]

Up to 30% faster:

All
  Comparison
    1000000
      insert
        vector-hashtables boxed:        OK
          37.9 ms ± 975 μs,       same as baseline
        vector-hashtables unboxed keys: OK
          26.0 ms ± 243 μs,       same as baseline
        vector-hashtables:              OK
          6.42 ms ± 121 μs, 26% less than baseline
      insert (resize)
        vector-hashtables boxed:        OK
          52.8 ms ± 849 μs,  3% less than baseline
        vector-hashtables unboxed keys: OK
          35.4 ms ± 657 μs,  4% less than baseline
        vector-hashtables:              OK
          11.2 ms ± 226 μs, 17% less than baseline
      insert, delete
        vector-hashtables:              OK
          10.6 ms ± 245 μs, 31% less than baseline
      find
        vector-hashtables:              OK
          4.40 ms ± 152 μs, 27% less than baseline
        vector-hashtables (frozen):     OK
          1.95 ns ±  56 ps,       same as baseline
      lookupIndex
        vector-hashtables:              OK
          2.73 ms ±  53 μs, 32% less than baseline
      fromList
        vector-hashtables:              OK
          16.4 ms ± 334 μs, 24% less than baseline
      toList
        vector-hashtables:              OK
          54.2 ms ± 2.0 ms,       same as baseline

[ulysses4ever]

Maybe you could update the table in README? It should be easy.

[Bodigrim]

Maybe you could update the table in README? It should be easy.

I can give it a go, but bear in mind that I'm on aarch64. It might be more representative for the majority of audience if numbers are generated on x86_64, I guess.

[ulysses4ever]

Good point. Let's hope we do it in the future then.

[ulysses4ever]

Let's wait a few days on this one to see if others are interested in chiming in. This is a core data structure change, so I'd love to see more opinions on what could go wrong.

[swamp-agr]

Initially, while writing helpers and benchmark, I forgot to add strictness to one of operators.

Good catch, thanks!