On 16 February 2014 17:25, Joaquin M Lopez Munoz
I think this nos the story the benchmarks tell. 15 different scenarios were tested:
* Insertion without rehashing, unique elements * Insertion with rehashing, unique elements * Insertion without rehashing, duplicate elements * Insertion without rehashing, duplicate elements, high load factor * Insertion with rehashing, duplicate elements * Insertion with rehashing, duplicate elements, high load factor * Erasure, unique elements * Erasure, dupicate elements * Erasure, dupicate elements, high load factor * Successful lookup, unique elements * Unsuccessful lookup, unique elements * Successful lookup, duplicate elements * Unsuccessful lookup, duplicate elements * Successful lookup, duplicate elements, high load factor * Unsuccessful lookup, duplicate elements, high load factor
and results do not show any definite winner (< means "better than"):
Well, of course I mostly noticed the results where Boost.Unordered did worse. I also wasn't paying much attention to the results for duplicate elements as I've found that most people don't care about them at all. One of the annoying things I've found is that the things I've spent time optimising are the things that users never benchmark. I think yours are the first benchmarks I've seen to deal with elements with equivalent keys. But what I'm not sure about, is how closely benchmarks reflect actual use. A minor dilemma that I've got at the moment is that on 64-bit machines the newer versions use a different bucket placement strategy to avoid the costly prime modulus. It's typically faster, but for certain cases (such as inserting consecutive integers) the old version is much faster as there are no collisions at all. The problem is I have no idea how often this happens in real world cases. It seems like something that will happen fairly often, so I could put in a special case for integers, but that would result in a performance hit for less regular numbers.