[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

Paolo Carlini paolo.carlini@oracle.com
Fri Nov 16 22:38:00 GMT 2012


Hi,

On 11/16/2012 10:58 PM, François Dumont wrote:
>     We can see that inserting the same elements again, that is to say 
> detecting the collisions, is slower in the new implementation. It is 
> the problem I had already signaled in bugzilla entry. In the new 
> implementation when we need to look for bucket elements we have to 
> check the hash code of each element to see if we are still in the same 
> bucket, in the former there was a nullptr to signal the end of the 
> bucket. I think I am going to try to add an empty node to mark the end 
> of the bucket. It will introduce a memory tradeoff of one empty node 
> for each non-empty bucket but it will also limit the impact of caching 
> the hash code or node because we won't need to use it so often.
Ok, seems and idea worth trying.

There is something I don't understand in the extended batch of insert 
performance tests: for the std:: containers I see much much less 
difference between the cached and non cached cases, compared to the old 
batch. How so? Is the insert performance impact of caching serious or 
not, I'm a bit confused now...

Paolo.



More information about the Libstdc++ mailing list