[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[François Dumont]

On 11/14/2012 11:48 PM, Paolo Carlini wrote:
> Hi,
>
> On 11/14/2012 10:27 PM, François Dumont wrote:
>> We do not cache if the following conditions are all met:
>> - key type is an integral
>> - hash functor is empty and not final
>> - hash functor doesn't throw
> Can somebody remind me why *exactly* we have a condition having to do 
> with the empty-ness of the functor?

     Because when hash code is not cache we need to embed the hash 
functor into the local iterator implementation. So to minimize local 
implementation memory footprint we prefered to cache the hash code as 
soon as it is not empty.

> I don't really understand it (and it's always tricky vs final). 
> Otherwise I think we are coming to the conclusion that we could simply 
> keep only the last condition possibly with the string (and wstring, 
> etc) special cases for std::hash specializations + documentation 
> explaining that the user can direct the behavior wrt caching via 
> noexcept on the call operator.
>

     Isn't gcc going to consider functor as noexcept even without the 
noexcept qualifier ? Analyzing the code gcc could guess it, no ? And 
isn't adding noexcept going to change potential optimization of the 
functor ? Users might not being force to forget about optimization just 
to cache hash code or not.

     I rather appreciate the idea but I would like to be sure it won't 
have any impact.

François