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++/54075] [4.7.1] unordered_map 3x slower than 4.6.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075

Dennis Lubert <plasmahh at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |plasmahh at gmx dot net

--- Comment #8 from Dennis Lubert <plasmahh at gmx dot net> 2012-07-24 10:41:54 UTC ---
I just stumbled over this bug while searching for something related to the max
load factor (it seems that since 4.7 the hashtable also shrinks when you set
the load factor higher, which is at least for me unfortunate).

I did just change the testcase to count the number of rehashes (by checking
bucket count before and after insert) and found:

gcc4.6 without reserve: 21
gcc4.6 with reserve: 1

gcc4.7 without reserve: 155
gcc4.7 with reserve: 160

Then in callgrind I had a look and most time seems to be spend in rehashing. So
I would assume that when the 4.7 version gets the number of rehashing down to
where it was, then we also get the speed down to where it was.

I would say that the reserve behaviour though is definetly broken, as it even
increases the amount of rehashings. I personally would just not have the
hashtable ever shrink on insert and/or load factor setting, just only ever on
explicit rehash() calls...


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