public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/63466] New: sstream is very slow
@ 2014-10-06 16:56 andi-gcc at firstfloor dot org
  2014-10-06 17:59 ` [Bug libstdc++/63466] " glisse at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-10-06 16:56 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 63466
           Summary: sstream is very slow
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andi-gcc at firstfloor dot org

sstream is very slow. Comparing two simple programs that parse a stream with C
and with sstream. The sstream version is an order of magnitude slower.

gcc version 4.9.1 20140423 (prerelease) (GCC) 

# C++
% time ./a.out  < testfile 

real    0m0.893s
user    0m0.888s
sys    0m0.004s


# C
time ./tstream-c  < testfile 

real    0m0.032s
user    0m0.030s
sys    0m0.001s

Here's a profile.

    16.13%    a.out  libc-2.18.so         [.] _IO_getc                          
    10.39%    a.out  libc-2.18.so         [.] _IO_ungetc                        
     9.15%    a.out  libstdc++.so.6.0.20  [.] std::basic_istream<char,
std::char_traits<char> >& std::getline<char, std::char_traits<char>,
std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char)  
     7.87%    a.out  libstdc++.so.6.0.20  [.] __dynamic_cast                    
     4.99%    a.out  libc-2.18.so         [.] __GI___strcmp_ssse3               
     3.95%    a.out  libstdc++.so.6.0.20  [.] std::basic_istream<char,
std::char_traits<char> >& std::operator>><char, std::char_traits<char>,
std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)        
     3.89%    a.out  libc-2.18.so         [.] _int_free                         
     2.79%    a.out  libstdc++.so.6.0.20  [.]
__cxxabiv1::__vmi_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const
     2.65%    a.out  a.out                [.] main                              
     2.58%    a.out  libc-2.18.so         [.] malloc                            
     2.30%    a.out  libstdc++.so.6.0.20  [.]
__cxxabiv1::__si_class_type_info::__do_dyncast(long,
__cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info
const*, void const*, __cxxabiv1::__class_type_info const*, void const*,
__cxxabiv1::__class_type_info::__dyncast_result&) const 
     1.96%    a.out  libc-2.18.so         [.] _int_malloc                       
     1.86%    a.out  libstdc++.so.6.0.20  [.]
std::istream::sentry::sentry(std::istream&, bool)                               
     1.55%    a.out  libc-2.18.so         [.] _IO_sputbackc                     
     1.51%    a.out  libstdc++.so.6.0.20  [.]
__gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::underflow()       

Test case:

Generate test file:

 perl -e 'for($i=0;$i<1000000;$i++) { printf("%d %d\n", $i, $i); } ' > testfile

C++ version:

#include <iostream>
#include <string>
#include <sstream>

using namespace std;

void __attribute__((noinline, noclone)) func(string &, string &)
{
}

int main()
{
        string line;
        while (getline(cin, line)) {
                istringstream iss(line);
                string index, s;

                if (!(iss >> index >> s))
                       continue;
                func(index, s);
        }
        return 0;
}

C version:

#define _GNU_SOURCE 1
#include <stdio.h>
#include <string.h>

void __attribute__((noinline, noclone)) func(char *a, char *b)
{
}

int main()
{
        char *line = NULL;
        size_t linelen = 0;
        while (getline(&line, &linelen, stdin) > 0) {
                char *p = line;
                char *a = strsep(&p, " \t\n");
                char *b = strsep(&p, " \t\n");
                func(a, b);
        }
        return 0;
}


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

* [Bug libstdc++/63466] sstream is very slow
  2014-10-06 16:56 [Bug libstdc++/63466] New: sstream is very slow andi-gcc at firstfloor dot org
@ 2014-10-06 17:59 ` glisse at gcc dot gnu.org
  2014-10-06 18:13 ` andi-gcc at firstfloor dot org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-10-06 17:59 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
To be a bit less unfair, you could pull the declarations of the 3 variables out
of the loop. Even if optimizations are possible, I doubt we can go anywhere
near the C perf...


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

* [Bug libstdc++/63466] sstream is very slow
  2014-10-06 16:56 [Bug libstdc++/63466] New: sstream is very slow andi-gcc at firstfloor dot org
  2014-10-06 17:59 ` [Bug libstdc++/63466] " glisse at gcc dot gnu.org
@ 2014-10-06 18:13 ` andi-gcc at firstfloor dot org
  2014-10-07 10:31 ` redi at gcc dot gnu.org
  2014-10-07 10:39 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-10-06 18:13 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Looking at the profile there's plenty of room for optimization. e.g. not using
getc/ungetc, but directly accessing the buffer, or maybe even some kind of
template specialization.

With the variables pulled out it's faster, but still a lot slower than C:

% time ./a.out < testfile 
real    0m0.400s
user    0m0.397s
sys    0m0.002s
% time ./tstream-c < testfile

real    0m0.033s
user    0m0.028s
sys    0m0.004s


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

* [Bug libstdc++/63466] sstream is very slow
  2014-10-06 16:56 [Bug libstdc++/63466] New: sstream is very slow andi-gcc at firstfloor dot org
  2014-10-06 17:59 ` [Bug libstdc++/63466] " glisse at gcc dot gnu.org
  2014-10-06 18:13 ` andi-gcc at firstfloor dot org
@ 2014-10-07 10:31 ` redi at gcc dot gnu.org
  2014-10-07 10:39 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-07 10:31 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You're comparing apples and oranges.

This function forces you to do additional allocations for the arguments, which
has nothing to do with iostream performance:

  void __attribute__((noinline, noclone)) func(string &, string &)

This allocates even more memory:

                istringstream iss(line);

The expression (iss >> index >> s) is far more flexible than your C version,
handling adjacent whitespace and being able to extract arbitrary types from the
stream.

If you don't need those extra allocations and flexibility then don't use them;
your C code is a valid C++ program too. But rewriting your C++ code to be
equivalent to the C code (e.g. by using std::string::find_first_of) would
remove any use of stringstream, leaving only the performance of std::getline as
a limiting factor, which is not the topic of this bug report.

So if your point is simply "iostreams are slower than stdio" then yes, we know,
welcome to 1998 ;-)


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

* [Bug libstdc++/63466] sstream is very slow
  2014-10-06 16:56 [Bug libstdc++/63466] New: sstream is very slow andi-gcc at firstfloor dot org
                   ` (2 preceding siblings ...)
  2014-10-07 10:31 ` redi at gcc dot gnu.org
@ 2014-10-07 10:39 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-07 10:39 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The calls you see to getc are nothing to do with <sstream>, they're from the
std::getline call reading from stdin, and are required because you didn't tell
the C++ runtime that you don't need it to be synchronised with C stdio. If you
don't need to mix C and C++ I/O then you forgot the most important thing for
iostream performance on standard I/O streams:

  std::ios::sync_with_stdio(false);

If you don't need that synchronisation, don't use it.

Something like this is a more accurate equivalent of the C program, and much
closer in performance:

#include <iostream>
#include <string>
#include <sstream>

using namespace std;

void __attribute__((noinline, noclone)) func(char*, char*)
{
}

int main()
{
  std::ios::sync_with_stdio(false);
  string line;
  while (getline(cin, line)) {
    char* a = &line[0];
    char* b = nullptr;
    auto pos1 = line.find_first_of(" \t\n");
    if (pos1 != std::string::npos) {
      line[pos1] = '\0';
      b = a + pos1 + 1;
      auto pos2 = line.find_first_of(" \t\n", pos1+1);
      if (pos2 != std::string::npos) {
        line[pos2] = '\0';
      }
    }
    func(a, b);
  }
}


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

end of thread, other threads:[~2014-10-07 10:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-06 16:56 [Bug libstdc++/63466] New: sstream is very slow andi-gcc at firstfloor dot org
2014-10-06 17:59 ` [Bug libstdc++/63466] " glisse at gcc dot gnu.org
2014-10-06 18:13 ` andi-gcc at firstfloor dot org
2014-10-07 10:31 ` redi at gcc dot gnu.org
2014-10-07 10:39 ` 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).