Reading from stdin is 10x slower than libstdc++

[llvmbot]

Bugzilla Link	21192
Version	unspecified
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@hfinkel,@hiraditya,@mclow

Extended Description

If I have a large file and want to read the contents line by line using iostream, the performance of libc++ is around 10x worse than that of libstdc++. Below is a comparison of a simple line counter for a binary compiled with g++ 4.9, clang 3.5 and the standard coreutils wc tool. More discussion here:

http://info.prelert.com/blog/stdgetline-is-the-poor-relation

Profiling seems to confirm that with libc++ a mutex is held for each single character read from stdin.

$cat wc.cc

#include <iostream>
#include <string>

int main() {
  std::ios_base::sync_with_stdio(false);
  std::size_t i = 0;
  for (std::string line; std::getline(std::cin, line);) i++;
  std::cout << i << std::endl;
}

$ g++-4.9 --version
g++-4.9 (Homebrew gcc 4.9.1) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-4.9 -O3 wc.cc -o wc
$ time gzip -cd large_file.gz|head -n 100000 | ./wc
100000

real 0m2.811s
user 0m2.953s
sys 0m0.408s
$ c++ --version
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ c++ -O3 wc.cc -o wc
$ time gzip -cd large_file.gz|head -n 100000 | ./wc
100000

real 0m24.420s
user 0m27.114s
sys 0m0.322s
$ time gzip -cd large_file.gz|head -n 100000 | wc -l
100000

real 0m2.888s
user 0m3.229s
sys 0m0.304s

[llvmbot]

So any news on this problem?

This happens probably because of strange implementation of sync_with_stdio in libc++.

You can check it here:
https://github.com/llvm-mirror/libcxx/blob/6a85e8a355be05b9efa8408f875014e6b47cef3b/src/ios.cpp#L458

[hfinkel]

So any news on this problem?

This happens probably because of strange implementation of sync_with_stdio
in libc++.

You can check it here:
https://github.com/llvm-mirror/libcxx/blob/
6a85e8a355be05b9efa8408f875014e6b47cef3b/src/ios.cpp#L458

FWIW. This is still a significant problem. I just tried the test program with r271873:

$ clang++ -O3 -std=c++11 -o /tmp/w-gnu wc.cc
$ clang++ -O3 -std=c++11 -stdlib=libc++ -o /tmp/w-llvm wc.cc

$ /tmp/w-gnu < /lib64/libLLVM-3.6-mesa.so

This takes approximately 0.01 seconds

$ /tmp/w-llvm < /lib64/libLLVM-3.6-mesa.so

This takes approximately 0.5 second, almost 50x slower than using libstdc++ 4.8.5.

[llvmbot]

It looks like we ignore 'sync_with_stdio(false)' entirely, which is entirely conforming but also decidedly slow.

[mclow]

It looks like we ignore 'sync_with_stdio(false)' entirely, which is entirely conforming but also decidedly slow.

Yes, we do.

Relevant info: http://stackoverflow.com/questions/33837349/why-stdios-basesync-with-stdio-isnt-implemented-in-libc-clang

I suspect that implementing this would different mechanisms for each C library that libc++ uses.

[hfinkel]

It looks like we ignore 'sync_with_stdio(false)' entirely, which is entirely conforming but also decidedly slow.

Yes, we do.

Relevant info:
http://stackoverflow.com/questions/33837349/why-stdios-basesync-with-stdio-
isnt-implemented-in-libc-clang

I suspect that implementing this would different mechanisms for each C
library that libc++ uses.

I'm not under the impression that's how other implementations work. The point is whether our streams do their own buffering, or whether we directly forward all requests to the libc fwrite, etc. functions.

As a quick experiment, I modified our fstream header like this:

@@ -528,7 +528,10 @@
         }
         if (__rt)
         {
-            __file_ = fopen(__s, __mdstr);
+            if (__s[0] == '-' && !__s[1])
+              __file_ = fdopen(fileno(stdin), __mdstr);
+            else
+              __file_ = fopen(__s, __mdstr);
             if (__file_)
             {
                 __om_ = __mode;

and then I replaced the use of std::cin in the test with an ifstream object with "-" as the file name. This was ~2.6x faster than using std::cin. Still, however, nowhere near as fast as libstdc++ (which is ~50x faster).

[hiraditya]

Hi Hal, Nickolay,

Do you still see the problem, I added a patch to libc++ last year (https://reviews.llvm.org/D21103) which might have helped. Please let me know.

[hiraditya]

benchmarking using quick-bench shows std::getline is 3x slower even without std::ios_base::sync_with_stdio(false);

gcc: https://quick-bench.com/q/S2LGUrHKnYSn1y8WR-AyKh8jrF4 ​
clang: https://quick-bench.com/q/nuv3RspJoDe6Eh2ZMtSq8DLKHIs​
​
Here is the benchmark code in case the references don't work in future

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

static void construct_istream(std::istringstream& input) {
  std::string str;
  for (int i = 0; i < 10000; ++i)
    str += "asdkljadsflkjasd;flkjasdlfjdasfj7\n";
  input.str(str);
}

static void GetlineBench(benchmark::State& state) {
  // read file line by line
  std::istringstream input;
  construct_istream(input);
  for (auto _ : state) {
    std::string line;
    std::getline(input, line);
  }
}

BENCHMARK(GetlineBench);

[dandjelkovic96]

I encountered this issue after switching from libstdc++ to libc++ with Clang 13.0.1 and C++14. Is there a workaround or a solution to address this problem?

[ldionne]

#121346 will fix the std::getline performance issue discussed above.