Edit 2023-01-12: See comments! Test is flawed - it will never add more than 7 elements to the HashMap
. I've left the original results here unedited.
Test results on an Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
CPU:
$ cargo bench
Compiling bench_test v0.1.0 (file:///home/daboross/bench_test)
Finished release [optimized] target(s) in 2.99 secs
Running target/release/deps/bench_test-6b454ea06156805a
running 6 tests
test tests::bench_10_item_hash_map ... bench: 35 ns/iter (+/- 4)
test tests::bench_10_item_vec ... bench: 29 ns/iter (+/- 2)
test tests::bench_20_item_hash_map ... bench: 33 ns/iter (+/- 1)
test tests::bench_20_item_vec ... bench: 51 ns/iter (+/- 6)
test tests::bench_50_item_hash_map ... bench: 35 ns/iter (+/- 2)
test tests::bench_50_item_vec ... bench: 129 ns/iter (+/- 1)
test result: ok. 0 passed; 0 failed; 0 ignored; 6 measured
Conclusion: Vec is best when there are 15 or fewer items, HashMap is better when there are more than 15.
You're completely correct!
I can't believe I've come back to this gist so many times without noticing this error.
I don't know if I stated this in the original document, but for
fern
's use case, misses are expected to be much more common than hits, and thus this test does exclusively test misses. Even in the original test, the test string "q3428f9" doesn't appear in the preselected list of things to add to each.I think the fact that the test resulted in roughly what I was expecting (vec better at smaller magnitudes, hashmap better at larger ones) helped me miss this.
If I were to recreate the test fully today, I think I'd probably want to include some real-world data on how many hits vs. misses are expected, and distribute the test string in a random place in the vec/hashmap to account for that as well.
Thanks for catching this!