This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, François Dumont <frs dot dumont at gmail dot com>, "paolo.carlini at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Thu, 08 Nov 2012 03:25:56 +0100
- Subject: Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
- References: <bug-54075-19885@http.gcc.gnu.org/bugzilla/> <bug-54075-19885-8bKDxmpStr@http.gcc.gnu.org/bugzilla/> <509ADA7E.7050504@gmail.com> <CAH6eHdRHCefZq1FQF64nJ04-OMgMBb8TeUa5y9Lvi-2H=xE0Ww@mail.gmail.com> <509B1130.7050401@oracle.com>
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.