This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
- From: "andrewjcg at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 24 Jul 2012 21:45:55 +0000
- Subject: [Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
- Auto-submitted: auto-generated
- References: <bug-41975-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
Andrew Gallagher <andrewjcg at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrewjcg at gmail dot com
--- Comment #35 from Andrew Gallagher <andrewjcg at gmail dot com> 2012-07-24 21:45:55 UTC ---
It appears that http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181677 has
caused some performance regression in gcc-4.7 (or I am missing something). The
following example runs 3 times faster with gcc-4.6 than with gcc-4.7:
#include <unordered_map>
using namespace std;
int main() {
unordered_map<int, int> m;
//m.rehash(10000000);
for (int i = 0; i < 10000000; i++) {
m[i] = i;
}
}
Looking at a profile generated by google-perftools, it seems that most of the
time is spent in _M_rehash with gcc-4.7, as the newly rehashed size is
considerably smaller than in gcc-4.6 (perhaps due to the removal of
_M_growth_factor?), therefore it gets called a lot more often. Is this
expected behavior?
Reserve/rehash also appears to be broken. If the 'rehash' line is uncommented
in the example above, then a subsequent insert hits the check against
_M_prev_resize in _M_need_rehash and rehashes the bucket size back to a small
value.