[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