https://svn.boost.org/trac10/ticket/4308 <p> Hello </p> <p> The hashed_index within the multi_index project has such a major performance problem on anything that erases (i.e. erase, replace, modify) that the hash_index is unusable unless one never erases. </p> <p> The bug is reproduced by: </p> <ul><li>rehash()ing the table to 2 million buckets </li><li>inserting an element (which is correctly O(1)) </li><li>erasing that element </li></ul><p> Yes, the hashed_index is documented to be O(size of bucket vector), but it should not be. erase on a hash table should be O(1) just like in the TR1. </p> <p> A Possible solution to this bug is to keep an intrusive list of the nodes in the table, so begin() and the returned iterator are O(1). Another possible solution is to make begin() O(size of bucket vector) which is acceptable given that begin() is a linear interface. </p> <p> Obviously, the initial rehashing of the buckets to 1 million is standard practice for optimizing hash table performance, so this should not be eliminated. Since, the bucket vector never shrinks, the problem can also be reproduced by insert()ing 2 million objects, then erase()ing them. The erase()ing will take forever. </p> <p> Thanks, Sasha </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/4308 Trac 1.4.3 Joaquín M López Muñoz Tue, 08 Jun 2010 06:01:56 GMT https://svn.boost.org/trac10/ticket/4308#comment:1 https://svn.boost.org/trac10/ticket/4308#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">duplicate</span> </li> </ul> <p> Hi Sasha, closing this as it's a duplicate of <a class="ext-link" href="https://svn.boost.org/trac/boost/ticket/4264"><span class="icon">​</span>#4264</a>, please follow the discussion there. </p> Ticket