[4.7.1] unordered_map insert still slower than 4.6.2

[Paolo Carlini]

On 11/08/2012 10:18 PM, François Dumont wrote:
> 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.
Good, good, I think we are getting there. Tomorrow I will analyze in 
some detail what you have been doing. First, however, a thought which I 
had today while driving, more details about  a subset of those issues.

Consider the constructors and rehash: do I understand correctly that we 
are doing work for _M_prev_resize (via the various _M_bkt_for_elements 
and _M_next_bkt helpers), only to eventually *zero* it? That is 
something that we should definitely avoid. Then, if we don't touch 
_M_prev_resize for those member functions we have only to also not use 
_S_growth_factor for those and we are back to something much simpler and 
close to the old tr1 version and solving the issue with rehash(n) which 
became like an old rehash(2 * n) and avoiding all those ugly 
M_rehash_policy._M_prev_resize = 0 by hand.

Paolo.