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