[Bug c++/59048] New: std::string operator== between std::string and const char* creates unecessary temporary object

[Bug c++/59048] New: std::string operator== between std::string and const char* creates unecessary temporary object

[luca.stoppa at bbh dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

            Bug ID: 59048
           Summary: std::string operator== between std::string and const
                    char* creates unecessary temporary object
           Product: gcc
           Version: 4.4.7
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luca.stoppa at bbh dot com

Template functions
bool operator==( const char*, const std::string& ) and
bool operator==( const std::string&, const char* )
creates unecessary temporary std::string object. I'm using mainly GCC 4.4.7,
but I have tested GCC 4.8.3 and the behavior is exactly the same.

Look at this simple example:
1) here we call operator==(std::string&, const char*):
size_t f(const std::string &str)
{
    size_t result = 0;
    size_t len = str.size();
    for (size_t i=0; i<len; ++i)
        if (str == "ST")
            result += i;
    return result;
}

2) here we call operator==(const char*, const std::string&)
size_t h(const std::string &str)
{
    size_t result = 0;
    size_t len = str.size();
    for (size_t i=0; i<len; ++i)
        if ("ST" == str)
            result += i;
    return result;
}

3) here a basic const char* version
size_t ii(const char *str)
{
    size_t result = 0;
    size_t len = strlen(str);
    for (size_t i=0; i<len; ++i)
        if (0 == strcmp(str,"ST"))
            result += i;
    return result;
}

4) here a mixed version: std::string compared with strcmp().
size_t g(const std::string &str)
{
    size_t result = 0;
    size_t len = str.size();
    for (size_t i=0; i<len; ++i)
        if (0 == strcmp(str.c_str(),"ST"))
            result += i;
    return result;
}

This is the main I used to test these functions:
int main(int argc, char **argv )
{
    long how_many_times=atol( argv[1] );
    std::string events[]={ "CASH", "EQ", "FI", "FT", "FWD", "OP", "ST" };
    size_t result=0;
    for (size_t i=0; i<how_many_times; ++i)
        for (size_t j=0; j<elements(events); ++j)
            result += f(events[j]);

    std::cout <<result <<std::endl;
    return 0;
}

Few things to notice: running time ./a.out
f() will produce:
bash-4.1$ time ./a.out 10000000
10000000
real    0m4.222s

g() will produce:
bash-4.1$ time ./a.out 10000000
10000000
real    0m1.036s

h() will produce:
bash-4.1$ time ./a.out 10000000
10000000
real    0m4.223s

ii() (if we change in main() std::string events[]={...} into const char*
events[]={...}) will produce:
bash-4.1$ time ./a.out 10000000
10000000
real    0m1.266s
if I remove the call to strlen() will be basically 0seconds.

Which is the problem?
The problem here is that: why f()/h() are taking basically 4times more then
g()? The only different is how we compare strings. It seems like that f() and
h() are creating a temporary std::string object. Shouldn't we have the same
performance? It seems like the compare() method of the char_trait<char> could
be better implemented.

As a final notice: I have compiled all examples with g++ -O3 (Linux 64 and
MacOS Snow Lion).

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-11-08
          Component|c++                         |libstdc++
     Ever confirmed|0                           |1
           Severity|major                       |normal

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
4.4.7 has been unmaintained for years.

Please provide a proper testcase, not several incomplete snippets that force
people to recreate your tests.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Luca Stoppa from comment #0)
> Template functions
> bool operator==( const char*, const std::string& ) and
> bool operator==( const std::string&, const char* )
> creates unecessary temporary std::string object.

Where?

> It seems like that f()
> and h() are creating a temporary std::string object.

If you look at the code or use a debugger you can see there is no temporary
created, so you'll need to explain why you think that.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[luca.stoppa at bbh dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #3 from Luca Stoppa <luca.stoppa at bbh dot com> ---
Created attachment 31181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31181&action=edit
testcase

g++ -O3 mapping.cpp

time ./a.out 10000000 f
time ./a.out 10000000 g
time ./a.out 10000000 h
time ./a.out 10000000 i

will execute the 4 different paths in the code.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Indeed, I had a look to f and the correct operator== and compare are called, no
temporaries. By the way, type_traits<char> uses memcmp not strcmp.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[luca.stoppa at bbh dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #5 from Luca Stoppa <luca.stoppa at bbh dot com> ---
Thanks a lot,
so if memcmp() is called, how can the difference in performance be explained?
In short:

std::string s="something";

if (s == "something") { ... }

and

if (0 == strcmp(s.c_str(),"something")) { ... }
? Probably I'm doing something wrong, or my testcase is invalid?

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The only major difference I see is that in the operator== case you make a call
to a PIC function in libstdc++.so, whereas strcmp can be inlined.

There's no temporary created though.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> ---
An important detail is that the compare functions aren't inline, and are
exported for basic_string<char>. Thus, for a fair comparison, the strcmp should
be in an attribute noinline helper (to be 100% correct, should be a memcmp).
I'm pretty sure this is all there is to it.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Right, it's also PIC.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[luca.stoppa at bbh dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #9 from Luca Stoppa <luca.stoppa at bbh dot com> ---
Created attachment 31182
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31182&action=edit
not inlined memcmp used.

[Bug libstdc++/59048] std::string operator== between std::string and const char* creates unecessary temporary object

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048

--- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> ---
memcmp is pure and gcc manages to pull it out of the loop (see the file created
by -fdump-tree-optimized). It is funny that -fno-builtin-strcmp makes the code
more than 2 times faster (the main difference I can see is using "repz cmpsb"
instead of a call to the libc function strcmp).

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[neleai at seznam dot cz]

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

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neleai at seznam dot cz

--- Comment #13 from Ondrej Bilka <neleai at seznam dot cz> ---
Yes, this is duplicate of following.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
Until thats fixed you should compile everything with -fno-builtin-strcmp
-fno-builtin-memcmp

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |DUPLICATE

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Let's mark it as a duplicate then.

*** This bug has been marked as a duplicate of bug 43052 ***
>From gcc-bugs-return-487907-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 03 06:35:00 2015
Return-Path: <gcc-bugs-return-487907-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 125135 invoked by alias); 3 Jun 2015 06:34:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 125073 invoked by uid 48); 3 Jun 2015 06:34:56 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/43052] [4.8/4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
Date: Wed, 03 Jun 2015 06:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.4.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc
Message-ID: <bug-43052-4-Ypmedpc2Ye@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-43052-4@http.gcc.gnu.org/bugzilla/>
References: <bug-43052-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00239.txt.bz2
Content-length: 503

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |manu at gcc dot gnu.org

--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
This is not assigned to anyone
>From gcc-bugs-return-487906-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 03 06:34:11 2015
Return-Path: <gcc-bugs-return-487906-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 124120 invoked by alias); 3 Jun 2015 06:34:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 123769 invoked by uid 48); 3 Jun 2015 06:34:07 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/43052] [4.8/4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
Date: Wed, 03 Jun 2015 06:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.4.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-43052-4-Jrcf65ol9n@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-43052-4@http.gcc.gnu.org/bugzilla/>
References: <bug-43052-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00238.txt.bz2
Content-length: 484

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luca.stoppa at bbh dot com

--- Comment #28 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 59048 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-487908-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 03 06:43:44 2015
Return-Path: <gcc-bugs-return-487908-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4912 invoked by alias); 3 Jun 2015 06:43:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4864 invoked by uid 55); 3 Jun 2015 06:43:40 -0000
From: "fxcoudert at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
Date: Wed, 03 Jun 2015 06:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fxcoudert at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66377-4-zZIbxNOiXR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66377-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66377-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00240.txt.bz2
Content-length: 366

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf377

--- Comment #5 from fxcoudert at gmail dot com <fxcoudert at gmail dot com> ---
Is this code old, or a regression introduced by the recent module-equivalence
patch (to reduce the module sizes)?

Does removing the code regress module size in the case of modules with equiv
used in modules used in modules etc?

FX

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |---

--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Ondrej Bilka from comment #13)
> Yes, this is duplicate of following.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

No it isn't. I made a comment related to that other PR, but IIRC the main point
here is that the function is not pulled out of the loop, which is independent
of how memcmp gets expanded.

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[hiraditya at msn dot com]

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

AK <hiraditya at msn dot com> changed:

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

--- Comment #17 from AK <hiraditya at msn dot com> ---
Now that we have string_view, will it be possible to avoid creating a copy?

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We don't create a copy.

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:1b65779f46f16b4fffd0591f5e58722c1e7cde8d

commit r13-1095-g1b65779f46f16b4fffd0591f5e58722c1e7cde8d
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jun 14 14:54:27 2022 +0100

    libstdc++: Inline all basic_string::compare overloads [PR59048]

    Defining the compare member functions inline allows calls to
    traits_type::length and std::min to be inlined, taking advantage of
    constant expression arguments. When not inline, the compiler prefers to
    use the explicit instantiation definitions in libstdc++.so and can't
    take advantage of constant arguments.

    libstdc++-v3/ChangeLog:

            PR libstdc++/59048
            * include/bits/basic_string.h (compare): Define inline.
            * include/bits/basic_string.tcc (compare): Remove out-of-line
            definitions.
            * include/bits/cow_string.h (compare): Define inline.
            * testsuite/21_strings/basic_string/operations/compare/char/3.cc:
            New test.

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for GCC 13.