This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unordered profile mode patch


Hi,

On 05/06/2013 10:00 PM, François Dumont wrote:
Hi

Here is the patch to fix the unordered containers profile mode. There are a number of enhancements/fixes: - Use inheritance to play code on instantiation/destruction. This way some constructors and assignment operators can be defaulted like in the normal implementation and then be deleted if the normal implementation has his special function deleted. - Extend the Inefficient Hash diagnostic to the unordered_multiset and unordered_multimap. Surprisingly __profcxx_hashtable_destruct2 was called without __profcxx_hashtable_construct2 so having only the performance drawback without beneficing from the diagnostic result. I implemented it by simply ignoring equivalent elements. - Do not collect data for the Inefficient Hash diagnostic if it is not On, it is a costly operation. - Use an implementation detail, the cached hash code, when possible. This is good for performance and mandatory for robustness because the hash functor can throw and the code is called from the destructor. Some tests were failing because of that since I had the __gnu_cxx::throw_value_* hash functor to conditionally throw. - Remove useless non-Standard insert(const value_type*, const value_type*) overloads.

I also add a missing & in the MoveOnly equality functor signature of 55043.cc test file. I don't think it was intentional and it was a problem for the profile modes that uses it.
Patch looks great to me. Thanks. Careful, another two or three of these and you risk being appointed profile-mode maintainer ;)

While we are at it, the _M_profile_destruct seem very large to be inline...
Regarding usage of cached hash code I realized that none of the Standard methods of the unordered containers allowed to benefit from it. There is no gate between iterator and local_iterator. Has a size_type bucket(const_iterator) signature been discussed ?
Not to my best knowledge, I would recommend raising the issue on the isocpp forums or the library evolution reflector. By the way, are you already subscribed to the reflectors? In case, just send an email to Andrew Koenig http://www.open-std.org/jtc1/sc22/wg21/docs/contacts

Thanks,
Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]