This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
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.