http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46659
--- Comment #9 from François Dumont <fdumont at gcc dot gnu.org> 2010-12-09 21:05:22 UTC --- testsuite performance suite already show very good results but this test is rather explicit too. What will perhaps surprise you is that the only optimization that can explain this difference is in the '++j'. This operation require the iterator to be incrementable which is checked using mostly !M_is_end(). This operation used to be performed with the creation of an internal safe iterator end() resulting in: - creation/destruction of this safe iterator with the respective insertion/deletion from the safe iterator list (with mutex locks) - additional checks when comparing this internal iterator with j. With the patch the check is done using a normal iterator avoiding all those operations.
