为什么读取stdin中的行比C ++慢得多？
我想比较使用Python和C ++的stdin字符串输入的读取行，并且很惊讶地看到我的C ++代码比等效的Python代码慢了一个数量级。 由于我的C ++很生疏，而且我还不是专家蟒蛇，所以请告诉我，如果我做错了什么或者我误解了某些东西。
（TLDR答案：包括声明： cin.sync_with_stdio(false)或者只是使用fgets代替。
TLDR结果：一直滚动到我的问题的底部并查看表格。）
C ++代码：
#include <iostream>
#include <time.h>
using namespace std;
int main() {
string input_line;
long line_count = 0;
time_t start = time(NULL);
int sec;
int lps;
while (cin) {
getline(cin, input_line);
if (!cin.eof())
line_count++;
};
sec = (int) time(NULL) - start;
cerr << "Read " << line_count << " lines in " << sec << " seconds.";
if (sec > 0) {
lps = line_count / sec;
cerr << " LPS: " << lps << endl;
} else
cerr << endl;
return 0;
}
// Compiled with:
// g++ -O3 -o readline_test_cpp foo.cpp
Python等效：
#!/usr/bin/env python
import time
import sys
count = 0
start = time.time()
for line in sys.stdin:
count += 1
delta_sec = int(time.time() - start_time)
if delta_sec >= 0:
lines_per_sec = int(round(count/delta_sec))
print("Read {0} lines in {1} seconds. LPS: {2}".format(count, delta_sec,
lines_per_sec))
这是我的结果：
$ cat test_lines | ./readline_test_cpp
Read 5570000 lines in 9 seconds. LPS: 618889
$cat test_lines | ./readline_test.py
Read 5570000 lines in 1 seconds. LPS: 5570000
编辑：我应该注意到，我在Mac OS X v10.6.8（Snow Leopard）和Linux 2.6.32（Red Hat Linux 6.2）下都尝试了这一点。 前者是一台MacBook Pro，后者则是一台非常强大的服务器，并不是说这样太贴切。
编辑2 :(删除此编辑，不再适用）
$ for i in {1..5}; do echo "Test run $i at `date`"; echo -n "CPP:"; cat test_lines | ./readline_test_cpp ; echo -n "Python:"; cat test_lines | ./readline_test.py ; done
Test run 1 at Mon Feb 20 21:29:28 EST 2012
CPP: Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 2 at Mon Feb 20 21:29:39 EST 2012
CPP: Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 3 at Mon Feb 20 21:29:50 EST 2012
CPP: Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 4 at Mon Feb 20 21:30:01 EST 2012
CPP: Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 5 at Mon Feb 20 21:30:11 EST 2012
CPP: Read 5570001 lines in 10 seconds. LPS: 557000
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
编辑3：
好吧，我尝试了JN的建议，试图让Python存储行读取：但它对python的速度没有任何影响。
我也尝试过JN的建议，将scanf转换为char数组，而不是将getline转换为std::string 。 答对了！ 这导致Python和C ++的性能相当。 （我的输入数据是3,333,333个LPS，顺便说一句，每个都只有三个字段的短行，通常约20个字符宽，有时甚至更多）。
码：
char input_a[512];
char input_b[32];
char input_c[512];
while(scanf("%s %s %sn", input_a, input_b, input_c) != EOF) {
line_count++;
};
速度：
$ cat test_lines | ./readline_test_cpp2
Read 10000000 lines in 3 seconds. LPS: 3333333
$ cat test_lines | ./readline_test2.py
Read 10000000 lines in 3 seconds. LPS: 3333333
（是的，我跑了几次。）所以，我想我现在将使用scanf而不是getline 。 但是，如果人们认为std::string / getline这种性能是典型和合理的，我仍然很好奇。
编辑4（是：最终编辑/解决方案）：
添加：
cin.sync_with_stdio(false);
在我上面的原始while循环之上立即产生比Python运行得更快的代码。
新的性能比较 （这是在我的2011年MacBook Pro上），分别使用原始代码，禁用同步的原始代码和原始Python代码，在具有20M行文本的文件上进行比较。 是的，我跑了几次，以消除磁盘缓存混淆。
$ /usr/bin/time cat test_lines_double | ./readline_test_cpp
33.30 real 0.04 user 0.74 sys
Read 20000001 lines in 33 seconds. LPS: 606060
$ /usr/bin/time cat test_lines_double | ./readline_test_cpp1b
3.79 real 0.01 user 0.50 sys
Read 20000000 lines in 4 seconds. LPS: 5000000
$ /usr/bin/time cat test_lines_double | ./readline_test.py
6.88 real 0.01 user 0.38 sys
Read 20000000 lines in 6 seconds. LPS: 3333333
感谢@Vaughn Cato的回答！ 任何精心制作的人们都可以做出很好的引用，人们可以指出为什么这种同步发生，它的意思，什么时候有用，什么时候可以禁用，将会被后人所高度赞赏。 :-)
编辑5 /更好的解决方案：
正如灰袍巫师甘道夫以下建议， gets甚至快于scanf或不同步cin方法。 我还了解到scanf和gets都是不安全的，并且由于潜在的缓冲区溢出而不应该被使用。 所以，我用fgets写了这个迭代，这是获得更安全的选择。 下面是我的同伴新手的相关内容：
char input_line[MAX_LINE];
char *result;
//<snip>
while((result = fgets(input_line, MAX_LINE, stdin )) != NULL)
line_count++;
if (ferror(stdin))
perror("Error reading stdin.");
现在，下面是在具有非常快的磁盘的快速服务器上使用更大文件（100M行;〜3.4 GB）的结果，比较Python代码，非同步cin和fgets方法，以及与wc实用程序进行比较。 [ scanf版本分割错误，我不想排除故障。]：
$ /usr/bin/time cat temp_big_file | readline_test.py
0.03user 2.04system 0:28.06elapsed 7%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 28 seconds. LPS: 3571428
$ /usr/bin/time cat temp_big_file | readline_test_unsync_cin
0.03user 1.64system 0:08.10elapsed 20%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 8 seconds. LPS: 12500000
$ /usr/bin/time cat temp_big_file | readline_test_fgets
0.00user 0.93system 0:07.01elapsed 13%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 7 seconds. LPS: 14285714
$ /usr/bin/time cat temp_big_file | wc -l
0.01user 1.34system 0:01.83elapsed 74%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
100000000
Recap (lines per second):
python: 3,571,428
cin (no sync): 12,500,000
fgets: 14,285,714
wc: 54,644,808
正如你所看到的， fgets比较好，但离wc性能还差得很远; 我很确定这是由于wc检查每个字符而没有任何内存复制的事实。 我怀疑在这一点上，代码的其他部分将成为瓶颈，所以即使可能的话，我也不认为优化到这个水平甚至是值得的（因为毕竟我实际上需要存储读取线在记忆中）。
还要注意，使用char *缓冲区和fgets与非同步cin进行字符串的小折衷是，后者可以读取任意长度的行，而前者要求将输入限制为某个有限数字。 在实践中，读取大多数基于行的输入文件可能不是问题，因为缓冲区可以设置为非常大的值，而不会被有效输入超出。
这是教育。 感谢大家的意见和建议。
编辑6：
正如JF Sebastian在下面的评论中所建议的那样，GNU wc实用程序使用plain C read() （在safe-read.c包装内）来一次读取16k字节块并计算新行。 下面是一个基于JF代码的Python等价物（只显示替代Python for循环的相关代码片段：
BUFFER_SIZE = 16384
count = sum(chunk.count('n') for chunk in iter(partial(sys.stdin.read, BUFFER_SIZE), ''))
这个版本的性能非常快（当然，仍然比原始的C wc工具慢）：
$ /usr/bin/time cat temp_big_file | readline_test3.py
0.01user 1.16system 0:04.74elapsed 24%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 4.7275 seconds. LPS: 21152829
同样，对于我来说，将C ++ fgets / cin和第一个Python代码与wc -l以及另一个Python代码片段进行比较对我来说有点愚蠢，因为后两者实际上并不存储读取的行，但是只需要换行符。 不过，探索所有不同的实现并考虑性能影响很有意思。 再次感谢！
编辑7：微小的基准附录和回顾
为了完整起见，我认为我会用原始（同步的）C ++代码更新同一个文件夹中相同文件的读取速度。 再次，这是一个快速磁盘上的100M行文件。 这里是完整的表格：
Implementation Lines per second
python (default) 3,571,428
cin (default/naive) 819,672
cin (no sync) 12,500,000
fgets 14,285,714
wc (not fair comparison) 54,644,808
默认情况下， cin与stdio同步，这会导致它避免任何输入缓冲。 如果您将其添加到主体的顶部，您应该看到更好的性能：
std::ios_base::sync_with_stdio(false);
通常，当缓冲输入流时，不会一次读取一个字符，而是以较大的块读取流。 这减少了系统调用的数量，这通常相对昂贵。 但是，由于基于FILE*的stdio和iostreams通常具有单独的实现并因此具有单独的缓冲区，因此如果两者一起使用，则可能会导致问题。 例如：
int myvalue1;
cin >> myvalue1;
int myvalue2;
scanf("%d",&myvalue2);
如果cin读取的输入比实际需要的多，那么第二个整数值将不可用于scanf函数，该函数具有自己的独立缓冲区。 这会导致意想不到的结果。
为了避免这种情况，默认情况下，流与stdio同步。 实现这一点的一种常见方式是让cin根据需要使用stdio函数逐个读取每个字符。 不幸的是，这会带来很多开销。 对于少量的输入，这不是一个大问题，但是当你阅读数百万行代码时，性能损失很大。
幸运的是，如果您知道自己在做什么，库设计人员决定也应该禁用此功能以提高性能，因此他们提供了sync_with_stdio方法。
出于好奇，我看了一下发生了什么，我在每次测试中都使用了dtruss / strace。
C ++
./a.out < in
Saw 6512403 lines in 8 seconds. Crunch speed: 814050
syscalls sudo dtruss -c ./a.out < in
CALL COUNT
__mac_syscall 1
<snip>
open 6
pread 8
mprotect 17
mmap 22
stat64 30
read_nocancel 25958
蟒蛇
./a.py < in
Read 6512402 lines in 1 seconds. LPS: 6512402
syscalls sudo dtruss -c ./a.py < in
CALL COUNT
__mac_syscall 1
<snip>
open 5
pread 8
mprotect 17
mmap 21
stat64 29
我在Mac上使用g ++在计算机上复制了原始结果。
在while循环之前将以下语句添加到C ++版本，使其与Python版本内联：
std::ios_base::sync_with_stdio(false);
char buffer[1048576];
std::cin.rdbuf()->pubsetbuf(buffer, sizeof(buffer));
sync_with_stdio将速度提高到2秒，并将较大的缓冲区设置为1秒。
链接地址: http://www.djcxy.com/p/823.html上一篇: Why is reading lines from stdin much slower in C++ than Python?
下一篇: What's the correct way to check if an object is a typing.Generic?