Consider moving string_view member functions to using "Deducing this" in C++23

[libbooze]

"Deducing this" was accepted for C++23, and although it will probably be years before Google uses it a lot of outside users can benefit from performance improvements sooner since we can upgrade compilers more easily.

It is unclear if moving to using "Deducing this" will improve performance, but it is mentioned in proposal as an example so it is reasonable to expect it will, but as usual benchmarking might be needed.

Additionally macros needed to get this working might be too ugly to tolerate from readability perspective, but that is up to you to balance. ⚖

You can see this part of proposal for details wrt performance, I am totally unrelated to it: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0847r7.html#by-value-member-functions-for-performance

P.S. Not sure if question is a good label, this is more of a feature request/performance bug, but only options I had were question and bug so question seemed better fit.

[tituswinters]

In the string_view case, I don't think we'd do anything here for a couple reasons:

1. The example presented in the paper isn't specifically (IIUC) asserting that such a change would be a performance win for the member functions of string_view. (Or at least, I certainly don't see where the extra memory fetch would come into play for that example.)
2. Our goal is for Abseil types like string_view to generally disappear when the relevant standard is available. string_view is a C++17 type - by the time there is good compiler support for C++23 we may well be removing Abseil support for string_view.

By and large the "Deducing this" stuff is a balance of simplicity and performance: I think the examples about optional<T>::value() are much clearer - we write the accessor code one time, forwarding along the const and ref qualifications of the current object/context.

On Sun, Mar 6, 2022 at 3:04 PM libbooze @.***> wrote:

"Deducing this" was accepted for C++23, and although it will probably be years before Google uses it a lot of outside users can benefit from performance improvements sooner since we can upgrade compilers more easily.

It is unclear if moving to using "Deducing this" will improve performance, but it is mentioned in proposal as an example so it is reasonable to expect it will, but as usual benchmarking might be needed.

Additionally macros needed to get this working might be too ugly to tolerate from readability perspective, but that is up to you to balance. ⚖

You can see this part of proposal for details wrt performance, I am totally unrelated to it:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0847r7.html#by-value-member-functions-for-performance

— Reply to this email directly, view it on GitHub https://github.com/abseil/abseil-cpp/issues/1122, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC7CRX4GIILYCKZEGTB6OUDU6UFWPANCNFSM5QBRQPNA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- *If you get an email from me outside of the 9-5 it is not because I'm always on or expect an immediate response from you; it is because of work flexibility http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html . Evening and weekend emails are a sign I allocated some regular working hours for other things (such as family, gym, friends,...). And I encourage you to feel free to do the same.

[libbooze]

1. The example presented in the paper isn't specifically (IIUC) asserting that such a change would be a performance win for the member functions of string_view. (Or at least, I certainly don't see where the extra memory fetch would come into play for that example.)

That is not how I understood the paper (and again I am not participating in standardization, so you are probably correct), but here is what I understand.

IIUC the paper says:

1. assume string_view member function is not inlined(not sure how realistic is this)
2. this is passed as pointer(reference technically, but it is a pointer at machine level), that means that to use string_view you need to "jump" through that pointer to get the interesting stuff(data and size). This is not expensive, but not free, and maybe increases the size of the executable. Example: https://godbolt.org/z/GP6aGEr7Y Unfortunately without you or somebody else rewriting some gigantic realistic application and benchmarking it this is all guesses, but AFAIK 3/4 authors of that paper work in trading companies, so I would guess they know a bit about optimization, and they wrote(directly referring to string_view like classes): Most of the member functions can be rewritten this way for a free performance boost.

Our goal is for Abseil types like string_view to generally disappear when the relevant standard is available. string_view is a C++17 type - by the time there is good compiler support for C++23 we may well be removing Abseil support for string_view.

Ah shame, I guess I misunderstood Abseil mission statement. I was hoping that Abseil could be planet for the ABI Resistance :), I think would be really nice if we had more performant string_view available for people who do not care about ABI compatibility.

In the end I want to thank you for replying, feel free to close this, or leave it open as a project for some future intern :)