[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2

["cracauer at cons dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #31 from Martin Cracauer <cracauer at cons dot org> 2012-10-25 17:47:45 UTC ---
The case I reported is in a large system. I did an isolated test case which
sees the time shoots up from 32.54 seconds in gcc-4.4 to 42.86 s in gcc-4.7 and
back down to 32.27s  when using gcc-4.7 with the tr1 hashtables.

As you can see there also is a reasonably catastrophic increase in minor page
faults.

gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 
extra flags:
meh: 1635550270 4081940 288998848
0:32.54 32.54 real 30.50 user 1.97 sys 99% CPU 0/1394855 faults
   text    data     bss     dec     hex filename
   5456     688 3840032 3846176  3ab020 sdriver

gcc version 4.7.2 (Debian 4.7.2-4) 
extra flags:
meh: 1635550270 4081940 288998848
0:42.86 42.86 real 40.21 user 2.56 sys 99% CPU 0/2101681 faults
   text    data     bss     dec     hex filename
   6822     760 3840032 3847614  3ab5be sdriver

gcc version 4.7.2 (Debian 4.7.2-4) 
extra flags: -DCRA_USE_TR1
meh: 1635550270 4081940 288998848
0:32.27 32.27 real 30.29 user 1.92 sys 99% CPU 0/1394853 faults
   text    data     bss     dec     hex filename
   5426     736 3840032 3846194  3ab032 sdriver

Profiles for the three cases:
http://www.cons.org/gcc-hash-slowdown/

Source code for test case:
http://www.cons.org/gcc-hash-slowdown/reproduce-slow-hash.tar.gz

Please feel free to copy things if you want to append things to this pr.

My original case with worse slowdown is in a complicated system and driven from
Lisp. For no other reason than Murphy's law the profiler in there does not
penetrate into layers of C++ frames for this run, although it normally does. So
I'm not able to break up the insert() into it's parts right now.  I have no
reason to believe that it is different than this test case, probably just a
slower hash.  I have seen gcc-4.7 + tr1 hashtable faster than gcc-4.4 both in
the large system and in the test case so I'm pretty confident that we are
looking at the same thing here. I'm fixing that profiler, more later.

Hope this helps.