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.
