Re: [hub] Post-review version ready
Joaquin M López Muñoz via Boost <[email protected]> Fri, 29 May 2026 19:27:14 +0200
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <[email protected]> |
El 29/05/2026 a las 2:02, Matt Bentley escribió: > > > 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. > Yes, hub could do something similar. The bad thing about _not_ being a container in the stdlib is that you must rely on the user doing ADL for it, as you mention. On a somewhat related note, Ion has been experimenting with efficient algorithms for segmented iterators: https://boostedcpp.net/2026/05/18/neoclassical-c-segmented-iterators-revisited-1/ Some stdlib implementations like libc++ use these techniques _internally_, which negates the potential benefits to external libraries. It'd be terrific if Ion could eventually work out a std proposal for this, but I don't know if this is his appetite. Joaquín M López Muñoz _______________________________________________ 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/HHA5M2TQHBWEQLFT5EM3OZY3KRPLBIHZ/