[4.7.1] unordered_map insert still slower than 4.6.2

Paolo Carlini paolo.carlini@oracle.com
Thu Nov 8 09:47:00 GMT 2012


.. something else I'm seeing today is that in _M_need_rehash we 
implement a grow policy which is rather different from what we used to 
have and we still do have in std::vector, for example: as soon as 
__min_bkts >= __n_bkt we essentially double the value inside 
_M_next_bkt. In the old code we computed the std::max of __min_bkts and 
2 * __n_bkt, which seems OK to me, I don't think we should change it.

But again, even if this is unrelated to slowdown reported in the audit 
trail (what do the profiles say?), I think we should really make sure 
that _M_next_bkt and _M_bkt_for_elements don't use _S_growth_factor 
(note, by the way, that the size of __fast_bkt was meant to cover also 
the default value of the bucket_hint constructor, which is 10).

In principle, it would be nice to also get rid of the double lower_bound 
call: one can already be quite expensive and I know that other 
implementers even decided to not use lower bound at all because of that. 
Unfortunately I missed that we were adding a second one, together with 
_M_prev_resize. Today there is a lot of new computational and conceptual 
complexity in these policy functions and I'm not at all sure it's 
unavoidable.

All in all, I think we have quite a bit of work to do before 4.8 is 
released, I believe we should really stabilize these things finally. 
I'll try to help (maybe Jon too?) but at the moment I think Francois is 
the person knowing this code in detail and I hope he can allocate some 
of his free time over the next weeks...

Thanks!
Paolo.



More information about the Libstdc++ mailing list