This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]