On Mon, 17 Feb 2025 at 11:59, François Dumont <frs.dum...@gmail.com> wrote: > > > On 16/02/2025 23:14, Jonathan Wakely wrote: > > On Sun, 16 Feb 2025 at 21:15, François Dumont <frs.dum...@gmail.com> wrote: > >> Hi > >> > >> A minor simplification. > >> > >> libstdc++: Simplify _Hashtable::_M_merge_multi > >> > >> When merging two hashtable instances of the same type we do not need > >> to go through _M_src_hash_code that also check for identical Hash functor > >> type. > > But that check is very cheap, do we really gain much here? > > No runtime gain no, just limit instantiations. > > > > > If we're getting rid of _M_src_hash_code in this overload of > > _M_merge_multi, should we get rid of it in the other overload too, > > since that's the only other place that uses _M_src_hash_code? > > Seems complicated, so maybe we can avoid is_same_v and is_empty_v with > this smaller patch ?
is_same_v and is_empty_v are extremely cheap, they are variable templates that use a compiler intrinsic. > > libstdc++: [_Hashtable] Avoid is_same_v and is_empty_v instantiations > > There is no need to check for same Hash functor type and this type > being stateless > if there is no hash code cached to reuse. > > libstdc++-v3/ChangeLog: > > * include/bits/hashtable.h (_Hashtable<>::_M_src_hash_code): > Add __hash_cached::value check. > > Let me know if interested. OK for trunk
