------- Comment #10 from paolo dot carlini at oracle dot com 2010-08-12 12:42 ------- > My comments on your last two posts:
Thanks Manuel. > I think the impact of this is independent of #579: even if erase > does not return an iterator, the cached bucket pointer has to > be synced. This happens for erase(const key_type&) as well as > erase(const_iterator). Of course, if erase(const_iterator) returns > an iterator then the cached bucket pointer cost is masked > (because you need to reach for the next non-empty bucket anyway). Totally agreed. > And yes, there is a non-negligible impact on doing the > cache thing. There was no discussion on this on the committe, so > we are basically on our own :-) I agree with you the impact > does not affect the O complexity of insert/erase, but it's > an impact nonetheless. The testcase provided is this: you > have an *empty* container with a large bucket count (because > it held a large number of elements before) and keep adding > and removing the same element: the resulting performance is > linear with the number of buckets. Whether this must be considered > or not a pathological use case I don't know. Agreed again. Now I begin to understand this issue ;) Anyway, the patch for our library is almost ready, already passes all my test. I'll apply it later today and start working on the even more serious erase(iterator) issue: during that work I will give more thinking to this one too, see if we can improve the QoI of erase(const key_type&) somehow. Let's keep in touch about these issues. Thanks again for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
