[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty

2009-11-29 Thread paolo dot carlini at oracle dot com
--- Comment #10 from paolo dot carlini at oracle dot com 2009-11-29 08:34 --- Stefan is right. The issue, in full generality, isn't trivial at all, there is now a new discussion on the library reflector. I'm under the impression that for C++0x we are not going to standardize the minimum

[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty

2009-11-28 Thread sstrasser at systemhaus-gruppe dot de
--- Comment #9 from sstrasser at systemhaus-gruppe dot de 2009-11-29 02:29 --- (In reply to comment #7) > An implementation is probably expected to shrink bucket_count when size > shrinks, so the complexity should still be O(size). That would be good > for memory use anyway, so why's t

[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty

2009-11-28 Thread sjackman at gmail dot com
--- Comment #8 from sjackman at gmail dot com 2009-11-29 00:44 --- I wouldn't depend on the number of buckets shrinking. Shrinking (and growing) a hash table is an expensive operation that requires rehashing all the elements in the hash table. Even if the implementation does provide the

[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty

2009-11-28 Thread rguenth at gcc dot gnu dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-28 23:16 --- An implementation is probably expected to shrink bucket_count when size shrinks, so the complexity should still be O(size). That would be good for memory use anyway, so why's that not done? -- http://gcc.gnu.or

[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty

2009-11-28 Thread jzwinck at gmail dot com
--- Comment #6 from jzwinck at gmail dot com 2009-11-28 22:59 --- The same bug has recently been raised in Boost's implementation of unordered containers: https://svn.boost.org/trac/boost/ticket/3693 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975