Re: [hub] Post-review version ready

On 29/05/2026 6:35 am, Joaquin M López Muñoz wrote:
> El 28/05/2026 a las 3:16, Matthew Bentley escribió:
>>
>> [...]
>> I'll add a note re: forced inlining. In the past I enabled this for 
>> some things like operator++, but found it pessimised. The compiler 
>> seems to be much better at this that we are. However, you'd need to 
>> measure before-and-after stats for your own case - not against my 
>> container (as forced inlining will definitely preferentially inline 
>> some of your code), but against your own pre-removal readings. 
>> Removing my container from that benchmark would probably help to get 
>> accurate results in this particular case.
>>
> I've checked locally in the past with and without forced inlining: GCC 
> and Clang do not seem to be really affected, but MSVC benefits a bit. 
> We observed a similar behavior when working with 
> boost::unordered_flat_map, my impression is that MSVC has a very low 
> inlining budget. I may revisit this again anyway, never hurts to 
> double check.
>
> Thank you,
>
> Joaquín M López Muñoz


Yes and to be fair it was a long time ago when I checked this, and 
compilers change their policies all the time :/

You might want to look at my overloads for distance/advance - they all 
follow the same pattern as range-erase (between O(1) and O(n), typically 
O(log n)). You'd have to use ADL of course.

Cheers,

M
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/SAEPEV5RO2E5JIRRUWK2UWE5MDSPRC4J/