[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
François Dumont
frs.dumont@gmail.com
Thu Nov 8 21:19:00 GMT 2012
On 11/08/2012 03:25 AM, Paolo Carlini wrote:
> On 11/08/2012 02:56 AM, Paolo Carlini wrote:
>> On the other hand, the old-old code for rehash didn't use
>> _M_growth_factor in these computations, it just literally enforced
>> the post-conditions of the Standard. Are we sure we aren't so to
>> speak rehashing too much? For example, when the load factor is very
>> low and doesn't count, it looks like a current rehash(n) accomplishes
>> the same of an old rehash(n * 2)?!? Something seems wrong, can you
>> double check that? In any case the comments before _M_next_bkt would
>> need fixing.
> ... in other terms, I really think that the only uses of
> _S_growth_factor should return to be inside _M_need_rehash, because
> that's the function called by the inserts, when the container must
> automatically grow the number of buckets. Elsewhere, like the
> constructors, rehash, should not need to know about _S_growth_factor.
>
> Paolo.
>
I haven't yet considered the following emails but based on those
good remarks I have done the attached patch. Surprisingly it seems to
have a good impact on performance even if before it
testsuite/performance/23_containers/insert/unordered_set.cc was showing
that new implementation was better.
I have also starting to adapt tests so that it's possible to check
unordered performance with std or std::tr1 implementations. Can I
generalize it to other tests ? If so, is it a good approach ?
François
-------------- next part --------------
A non-text attachment was scrubbed...
Name: performance.patch
Type: text/x-patch
Size: 5325 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20121108/f26027aa/attachment.bin>
More information about the Libstdc++
mailing list