3 ms·
Yes, but it's also important to understand what you lose when using these better-performing hashtables. First thing that comes to mind is that when performing a
by HippoBaro 8y ago
Yes, but it's also important to understand what you lose when using these better-performing hashtables.
First thing that comes to mind is that when performing a successful lookup on a std::unordered_map, the reference is guarrantied to be valid until either (a) you erase that element or (b) the table itself is destroyed.
Almost all faster hashtables around give up that properties for better lookup performance. Any insert operation might break all references.
So, in a sense, it's a bit unfair because std::unordered_map, in a real-world scenario, will potentially require you to perform less lookup because you can cache the references. With the others, you can't.
- allenz 8y agoYes, I agree with you that unordered_map should be slower. For context, the author shows off a graph where his custom Fibonacci implementation is the fastest, which proves nothing about Fibonacci hashing.
- stochastic_monk 8y agoI had an application several years ago in which the executable was 10x as fast when using khash instead of std::unordered_map.