[Bug libstdc++/54393] New: std::getline is almost 10x slower when working on a vstring versus std::string

[Bug libstdc++/54393] New: std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

             Bug #: 54393
           Summary: std::getline is almost 10x slower when working on a
                    vstring versus std::string
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bergner@gcc.gnu.org
                CC: azanella@linux.vnet.ibm.com
            Target: x86_64-linux, powerpc64-linux


Created attachment 28092
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28092
Compressed test input file.  Uncompress before using.

The following test case shows that the getline method is almost 10x slower when
reading into a vstring versus into a std::string.  This is true on both my
x86_64-linux and powerpc64-linux systems, so this seems to be a implementation
issue rather than a hardware issue.

bergner@otta:~/BUGS$ cat main.cc 
#include <iostream>
#include <fstream>
#include <string>

#ifdef VSTR
#include <ext/vstring.h>
typedef __gnu_cxx::__vstring STRING;
#else
typedef std::string STRING;
#endif

int
main(void)
{
  std::ifstream f ("test_input");
  STRING str;

  int max = 0;
  while (f)
    {
      std::getline (f, str);
      int len = str.length ();
      if (max < len)
    max = len;
    }
  printf ("max length = %d\n", max);
  return 0;
}
bergner@otta:~/BUGS$ g++ -O2 -UVSTR main.cc 
bergner@otta:~/BUGS$ time ./a.out 
max length = 432

real    0m0.257s
user    0m0.120s
sys    0m0.136s
bergner@otta:~/BUGS$ g++ -O2 -DVSTR main.cc 
bergner@otta:~/BUGS$ time ./a.out 
max length = 432

real    0m1.446s
user    0m1.320s
sys    0m0.120s

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> 2012-08-28 18:11:39 UTC ---
Created attachment 28093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28093
Test case as an attachment

Adding test case as an attachment.

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[azanella at linux dot vnet.ibm.com]

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

--- Comment #2 from Adhemerval Zanella <azanella at linux dot vnet.ibm.com> 2012-08-28 18:44:44 UTC ---
Created attachment 28094
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28094
__gnu_ext::__vstring getline optimization

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[azanella at linux dot vnet.ibm.com]

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

--- Comment #3 from Adhemerval Zanella <azanella at linux dot vnet.ibm.com> 2012-08-28 18:49:42 UTC ---
The default algorithm used on both std::string and __gnu_cxx::__vstring appends
data char by char. However, std::string also provides an template
specialization for both char and wchar_t (defined in src/istream.cc) which
appends the data from the stream using larger buffer (which is calculated by
finding the delimiter).

Based on that and following how std::string provides its template
specialization, I'm proposing a fix for the performance issue. This was made
against gcc-4.6 (I still working a patch for trunk) and I only update the
baseline_symbols for PPC64 (since it a still RFC patch).

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot
                   |                            |com

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> 2012-08-29 13:39:38 UTC ---
Adding Paolo for his comments, since he seems to be the author of the vstring
code.

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> 2012-08-29 13:43:16 UTC ---
Created attachment 28100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28100
Trunk version of the vstring patch

Here's a trunk version of Adhemerval's vstring patch.

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-29 13:53:23 UTC ---
No, I'm sorry, we are not going to do that for vstring. Remember that vstring
is just a preview of the new std::string implementation for when we break the
ABI. We are not going to add symbols and make things more complex for it. The
core issue is trivial, of course, when vstring will be "promoted" to main
string implementation will get the optimizations and everything else.

[Bug libstdc++/54393] std::getline is almost 10x slower when working on a vstring versus std::string

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

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

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> 2012-08-29 15:23:45 UTC ---
Ok, I knew that vstring was going to be used for the next std::string, so if
this will be fixed trivially once we make the switch, then that is good enough
for us.  I just wanted to make sure it would be fixed once we make the change. 
Thanks.