public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/66416] string::find_last_of 3.5 times slower than memrchr
       [not found] <bug-66416-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-24 17:19 ` hiraditya at msn dot com
  2024-02-19 16:51 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 2+ messages in thread
From: hiraditya at msn dot com @ 2020-03-24 17:19 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66416

AK <hiraditya at msn dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hiraditya at msn dot com

--- Comment #2 from AK <hiraditya at msn dot com> ---
Could it be because string::find is more optimized than string::rfind?
see: https://gcc.gnu.org/legacy-ml/libstdc++/2017-01/msg00034.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug libstdc++/66416] string::find_last_of 3.5 times slower than memrchr
       [not found] <bug-66416-4@http.gcc.gnu.org/bugzilla/>
  2020-03-24 17:19 ` [Bug libstdc++/66416] string::find_last_of 3.5 times slower than memrchr hiraditya at msn dot com
@ 2024-02-19 16:51 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 2+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-19 16:51 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66416

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-02-19
           Keywords|                            |missed-optimization
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=23112
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The problem is that string::find(char) uses std::char_traits::find, which is
optimized to use memchr, but there is no char-traits API for rfind, so
string::rfind(char) is a manual loop from the end of the string to the start.

We could add configure checks for memrchr and do something like:

--- a/libstdc++-v3/include/bits/string_view.tcc
+++ b/libstdc++-v3/include/bits/string_view.tcc
@@ -121,6 +121,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
        {
          if (--__size > __pos)
            __size = __pos;
+#if _GLIBCXX_HAVE_MEMRCHR
+         if constexpr (is_same_v<_Traits, char_traits<char>>)
+           {
+           if (auto __ptr = memrchr(_M_str, __c, __size))
+             return __ptr - _M_str;
+           }
+         else
+#endif
          for (++__size; __size-- > 0; )
            if (traits_type::eq(this->_M_str[__size], __c))
              return __size;

And then duplicate that in std::string::rfind, and ranges::find_last.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-02-19 16:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-66416-4@http.gcc.gnu.org/bugzilla/>
2020-03-24 17:19 ` [Bug libstdc++/66416] string::find_last_of 3.5 times slower than memrchr hiraditya at msn dot com
2024-02-19 16:51 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).