This is the mail archive of the
mailing list for the libstdc++ project.
Re: unordered profile mode patch
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 07 May 2013 11:30:23 +0200
- Subject: Re: unordered profile mode patch
- References: <51880BD9 dot 7060904 at gmail dot com>
On 05/06/2013 10:00 PM, François Dumont wrote:
Patch looks great to me. Thanks. Careful, another two or three of these
and you risk being appointed profile-mode maintainer ;)
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
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.
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