[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