为什么C++中的STDIN读行比Python慢得多？

Why is reading lines from stdin much slower in C++ than Python?

我想用Python和C++来比较STDIN中的字符串输入的读取行，并震惊地看到我的C++代码运行速度比等效的Python代码慢了一个数量级。因为我的C++是生疏的，我还不是一个专家，请告诉我，如果我做错了什么，或者如果我误解了什么。

(TLDR回答：包括声明：cin.sync_with_stdio(false)或仅使用fgets代替。

TLDR结果：一直向下滚动到问题的底部，然后查看表格。)

C++代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#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等价物：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#!/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))

以下是我的结果：

1
2
3
4
5

$ 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(雪豹)和Linux 2.6.32(Red Hat Linux 6.2)下都尝试过。前者是一个MacBookPro，后者是一个非常强大的服务器，而不是说这太中肯了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ 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

微小基准附录和摘要

为了完整起见，我想我会用原来的(同步)C++代码更新同一个文件上的读取速度。同样，这是用于快速磁盘上的100M行文件。以下是与几种解决方案/方法的比较：

1
2
3
4
5
6

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

相关讨论

您是否多次运行测试？可能存在磁盘缓存问题。
@沃恩卡托是的，还有两台不同的机器。
尝试将测试文件复制到另一个单独的文件中，以便将它们单独缓存。
@jjc：我看到两种可能性(假设您已经消除了david建议的缓存问题)：1)性能糟糕。这不是第一次。2)python足够聪明，不会在for循环中复制数据，因为您不使用它。你可以试着用scanf和char[]重新测试。或者，您可以尝试重写循环，以便对字符串进行处理(例如保留第5个字母并将其连接到结果中)。
还有一件事，这是一种简单的测试，它实际上并不反映语言n与语言m的性能。对于运行一个功能齐全的应用程序时无法得到的精确情况，Python可能有一个非常智能的优化。
@jjc，您可能应该使用time.time()而不是datetime.datetime.now().seconds；您得到浮点结果，并且在lps计算中不可能被零除。我在我的机器上得到了类似的测试结果(python大约快10倍)。
@J.N.如果我从每行中收集一个字符，那么python版本仍然要快得多。
@j n.python绝对不够聪明，无法避免复制数据。此外，还需要读取文件以查看换行符的位置。
文件有多大？除非行很长，否则我怀疑这可能是一个缓存问题。即缓存在运行之间不会被清除/破坏
@格尼布尔：有两份，你可以留一份
我用fscanf把差别缩小到3倍。这很奇怪，因为在某种程度上，Python必须使用底层的C API。
事实上，当使用较大的文件时，会有2次折叠(精度在1秒内太低)。
有没有可能python vm在将文件传输到stdin时会进行一些巧妙的缓冲读取，这样就不必每次读取一行数据时都输出到驱动器缓存中？
问题是与stdio同步——请看我的答案。
布伦丹，是的，C和C++也是如此。C python实现几乎可以肯定地依赖于stdio。现代系统Afaik中涉及到许多级别的缓存。
因为似乎没有人提到为什么你得到一个额外的行与C++：不要测试对EDCOX1，5！！将getline调用放入if语句中。
wc -l速度很快，因为它一次读取流的内容多于一行(可能是fread(stdin)/memchr('\
')的组合)。python结果的数量级相同，例如wc-l.py。
@J.F.Sebastian感谢您提供的python代码片段！看起来wc使用的是safe-read，它只是一个普通read的包装器，一次读取16k。修改python代码以使用16K缓冲区而不是32K，并在同一台机器和测试文件上运行它，这个压缩花费了4秒钟(即25000000 lps)，谢谢！
相关问题：stackoverflow.com/questions/8310039/&hellip；
好帖子。但我想提一下，scanf的缓冲区溢出问题可以通过指定要读取的字符数(对于任何数据类型)来处理。请参见链接中提到的宽度参数。例如：char s[10]；scanf("%9s"，s)；//这将从输入中读取最多9个字符。int x；scanf("%2d"，&；x)；//这将从输入中读取一个2位数字。(刚刚提到)这可以处理缓冲区溢出。也不能指定动态宽度，但要克服这一点，可以简单地生成
回答"为什么我的I/O很慢？"几乎总是"缓冲"。
哇，著名的问题！如果您想在wc的速度上获得性能，可以这样做：不调用逐行函数，而是准备好二进制块，一次检查一个int，使用新行字符的xor位掩码逻辑地屏蔽它们。(这通常会导致较少的单字节提取)。此外，使用stdio内置函数将其缓冲区指向您分配的缓冲区。然后您可以直接检查它。如果你真的想滥用stdio的话，还有更多的巫术，所以你甚至还没有达到极限，但是你现在可能已经达到了磁盘极限，所以滥用它毫无意义。
@谢谢，这些小贴士听起来不错！如果您碰巧有/编写/找到实现其中一些代码的简单示例代码，并将其作为答案(或至少链接)发布，我和这个问题的未来读者将非常感谢您的教学。干杯！
为了完整性，为什么不将快速Python版本和类似的C++代码添加到底部的图表中呢？您也可以考虑将图表移到顶部，因为人们可能在相当长的日志中找不到它。一本有趣的书！
根据stackoverflow.com/questions/21107131/&hellip；，只需将Python代码提取到函数中，就可以将其加速两次。
@你指的是什么"快速Python版本"？谢谢你的建议，我会把图表复制到最上面。
@JCC I的意思是编辑6的那个
另外，请看我在C++与Python中分割线的后续问题…类似的速度故事，其中天真的方法在C++中较慢！这里：stackoverflow.com/q/9378500/379037
这确实很有教育意义。并且再次强调C++是强大的事实，但是只有当它被小心地投入使用时才是事实。
如果我是你，我会看mmap和memchr函数。由于内存不是问题，请使用mmap映射程序中的整个文件，然后使用memchr处理以找出"行限制"。还有fadvise告诉内核你是按顺序读的
您还可以修复C++循环。循环中的额外测试可能会很昂贵。while (getline(cin, input_line)){line_count++;}
fscanf和scanf不一定是不安全的，但是要安全地使用它们有点笨拙，因为你必须使用%#s，如果你不想冒缓冲区溢出的风险，#比你的缓冲区小1，而不仅仅是%s。
JJC也许最有启发性的是，你的结果显示，从底层C STDIO库中获得的低级EDCOX1 6的方法比在C++中编码的任何东西快得多。理论上甚至可以用一个小的自定义C程序来击败这个数字，该程序迭代地将未缓冲的read系统调用转换成足够大的固定长度bufsize缓冲区，或者通过等效的mmap系统调用，然后快速地通过这个计数换行&；la for (char *cp = buf; *cp; cp++) count += *cp =="\
"，但是您可能仍然需要调整buf系统的大小与stdio的大小相同。

默认情况下，cin与stdio同步，从而避免任何输入缓冲。如果将此项添加到主项的顶部，您将看到更好的性能：

1	std::ios_base::sync_with_stdio(false);

通常，当一个输入流被缓冲时，而不是一次读取一个字符，该流将以更大的块读取。这减少了系统调用的数量，而系统调用通常比较昂贵。然而，由于基于FILE*的stdio和iostreams通常具有单独的实现，因此具有单独的缓冲区，如果两者一起使用，这可能会导致问题。例如：

1
2
3
4

int myvalue1;
cin >> myvalue1;
int myvalue2;
scanf("%d",&myvalue2);

如果cin读取的输入比实际需要的多，那么第二个整数值将不适用于scanf函数，该函数有自己的独立缓冲区。这将导致意想不到的结果。

为了避免这种情况，默认情况下，流与stdio同步。实现这一点的一种常见方法是让cin根据需要使用stdio函数一次读取每个字符。不幸的是，这会带来很多开销。对于少量的输入，这不是一个大问题，但是当您阅读数百万行时，性能损失是显著的。

幸运的是，库设计人员决定，如果您知道自己在做什么，也应该能够禁用此功能以获得更好的性能，因此他们提供了sync_with_stdio方法。

相关讨论

这应该在顶部。这几乎可以肯定是正确的。答案不能在于用fscanf调用替换read，因为这并不像python那样做太多的工作。Python必须为字符串分配内存，可能多次被认为是现有的分配不足-恰好类似于使用EDCOX1×1的C++方法。这个任务几乎肯定是I/O绑定的，对于在C++中创建EDCOX1、1个对象或使用EDOCX1和3本身的成本有太多的考虑。
是的，在我原来的while循环上面添加这一行，可以加快代码速度，甚至超过python。我将把结果作为最终编辑发布。再次感谢！
@沃恩卡托，事实证明，fgets更快，请看我的编辑5。尽管如此，您的解决方案还是非常有用的，特别是当需要使用CIN并写入字符串对象时，例如，在单行可能比预期长很多的上下文中，以及fgets->char buffer[maxline]路由将导致截断的上下文中。谢谢。
输出/打印怎么样？因为我觉得计数也很慢，是不是一样？
是的，这实际上也适用于cout、cerr和clog。
要使cout、cin、cerr和clog更快，请这样做std:：ios_base:：sync_with_stdio(false)；
很高兴我遇到这个问题。请记住，如果您使用cin.sync_与\stdio(false)解决方案，那么您的程序的任何其他部分都不应该从stdin读取！一篇关于流同步的优秀文章可以在drdobbs.com/184401305上找到。
很高兴我为这个烧掉了我每天的选票，我甚至没有到这里搜索，只是从一个完全武断的问题中看到了一个可能相关的列表。这对于那些进行速度敏感的cin输入的人来说是非常有用的，他们希望缓冲的好处。非常感谢，沃恩。回答得很好。
请注意，sync_with_stdio()是一个静态成员函数，对任何流对象(如cin调用)调用此函数都会为所有标准iostream对象打开或关闭同步。
@gjpc错了；如果我对同步的理解是正确的，那么只要它依赖于std::cin.rdbuf()，您仍然可以自由地做您想要做的事情。你不能用CSTDIO的stdin。
(P.S.或std::wcin)

出于好奇，我看了看引擎盖下面发生了什么，并在每个测试中使用了DTruss/Strace。

C++

1 2	./a.out < in Saw 6512403 lines in 8 seconds. Crunch speed: 814050

系统调用sudo dtruss -c ./a.out < in。

1
2
3
4
5
6
7
8
9

CALL COUNT
__mac_syscall 1
<snip>
open 6
pread 8
mprotect 17
mmap 22
stat64 30
read_nocancel 25958

Python

1 2	./a.py < in Read 6512402 lines in 1 seconds. LPS: 6512402

系统调用sudo dtruss -c ./a.py < in。

1
2
3
4
5
6
7
8

CALL COUNT
__mac_syscall 1
<snip>
open 5
pread 8
mprotect 17
mmap 21
stat64 29

我落后了几年，但是：好的。

在原始日志的"编辑4/5/6"中，您使用的是结构：好的。

1	$ /usr/bin/time cat big_file \| program_to_benchmark

这在两个不同的方面是错误的：好的。

实际上，您是在计时"cat"的执行，而不是您的基准。"time"显示的"user"和"sys"CPU使用率是"cat"的使用率，而不是基准程序的使用率。更糟糕的是，"实时"时间也不一定准确。根据"cat"和本地操作系统中管道的实现情况，"cat"可能会在读卡器进程完成工作之前编写最终的巨大缓冲区并退出。好的。

使用"cat"是不必要的，实际上会适得其反；你在添加运动部件。如果您使用的是一个足够旧的系统(即只有一个CPU，在某些代的计算机中，I/O速度比CPU快)，那么仅仅运行"cat"这个事实就可以大大改变结果。您还需要服从输入和输出缓冲以及其他处理'cat'。(如果我是Randal Schwartz，这很可能会给你赢得"无用的猫使用"奖。好的。

更好的结构是：好的。

1	$ /usr/bin/time program_to_benchmark < big_file

在这个语句中，它是一个shell，它打开一个大的文件，并将其作为一个已经打开的文件描述符传递给您的程序(实际上是传递给"time"，然后作为子进程执行您的程序)。100%的文件读取是您要测试的程序的严格责任。这可以让您真正了解它的性能，而不会出现虚假的复杂情况。好的。

我将提到两个可能的，但实际上是错误的，"修复"也可以考虑(但我用不同的方式对它们进行"编号"，因为这些不是原始帖子中出错的内容)：好的。

a.您可以通过只对程序进行计时来"修复"此问题：好的。

1	$ cat big_file \| /usr/bin/time program_to_benchmark

b.或通过对整个管道进行计时：好的。

1	$ /usr/bin/time sh -c 'cat big_file \| program_to_benchmark'

这些错误的原因与2相同：他们仍然不必要地使用"cat"。我提到它们有几个原因：好的。

对于那些对posix shell的I/O重定向功能不太满意的人来说，它们更为"自然"。好的。
在某些情况下，可能需要'cat'(例如：要读取的文件需要某种访问权限，而您不想将该权限授予要基准化的程序：'sudo cat/dev/sda/usr/bin/time my_compression_test--no output`)好的。
在实践中，在现代机器上，管道中添加的"cat"可能没有实际意义。好的。

但我迟疑地说了最后一句话。如果我们在"编辑5"中检查最后一个结果--好的。

1 2	$ /usr/bin/time cat temp_big_file \| wc -l 0.01user 1.34system 0:01.83elapsed 74%CPU ...

--这表明"cat"在测试期间消耗了74%的CPU；实际上，1.34/1.83大约是74%。也许是一段：好的。

1	$ /usr/bin/time wc -l < temp_big_file

只剩下0.49秒！可能不是这样："cat"必须支付read()系统调用(或等效调用)的费用，该调用从"disk"(实际上是缓冲区缓存)传输文件，以及将文件传输到"wc"的管道写入。正确的测试仍然需要执行那些read()调用；只有对pipe的写操作和从pipe调用中读取的操作才能被保存，而且这些操作应该非常便宜。好的。

不过，我预测你可以测量'cat file_wc-l'和'wc-l事实上，我在Linux 3.13(Ubuntu 14.04)系统上对一个1.5GB的垃圾文件进行了一些快速测试，获得了这些结果(这些实际上是"3中最好的"结果；当然，在启动缓存之后)：好的。

1
2
3
4
5
6

$ time wc -l < /tmp/junk
real 0.280s user 0.156s sys 0.124s (total cpu 0.280s)
$ time cat /tmp/junk | wc -l
real 0.407s user 0.157s sys 0.618s (total cpu 0.775s)
$ time sh -c 'cat /tmp/junk | wc -l'
real 0.411s user 0.118s sys 0.660s (total cpu 0.778s)

注意，这两个管道结果声称花费的CPU时间(user+sys)比实时时间多。这是因为我使用的是shell(bash)的内置"time"命令，它了解管道；我在一台多核机器上，管道中的独立进程可以使用独立的内核，从而比实时更快地累积CPU时间。使用/usr/bin/time，我发现CPU时间比实时时间要短——这表明它只能在命令行上对传递给它的单个管道元素计时。此外，shell的输出给出毫秒，而/usr/bin/time只给出百分之一秒。好的。

因此，在"wc-l"的效率水平上，"cat"有着巨大的区别：409/283=1.453或45.3%的实时性，775/280=2.768，或高达177%的CPU使用率！随机地，它就在时间测试箱里。好的。

我应该补充一点，在这些测试风格之间，至少还有一个显著的区别，我不能说这是有益的还是错误的；您必须自己决定：好的。

当你运行"cat big_file/usr/bin/time my_program"时，你的程序正以"cat"发送的速度从管道接收输入，并以不大于"cat"写入的块的形式接收输入。好的。

当您运行`/usr/bin/time my_program当然，如果同一个程序在两种情况下的执行方式明显不同，这是一个有趣的基准测试结果。它表明，实际上，程序或其I/O库正在做一些有趣的事情，比如使用mmap()。因此，在实践中，两种方式都运行基准可能是好的；也许通过一些小因素对"cat"结果进行折扣，以"原谅"运行"cat"本身的成本。好的。好啊。

相关讨论

我在我的电脑上用Mac电脑上的G++复制了原始结果。

在EDCOX1的12个循环之前，将下面的语句添加到C++版本中，使其与Python版本内联：

1
2
3

std::ios_base::sync_with_stdio(false);
char buffer[1048576];
std::cin.rdbuf()->pubsetbuf(buffer, sizeof(buffer));

同步与stdio将速度提高到2秒，设置更大的缓冲区将速度降低到1秒。

相关讨论

如果您不关心文件加载时间或加载小文本文件，那么getline、流运算符scanf非常方便。但是，如果性能是您关心的，那么您应该将整个文件缓冲到内存中(假设它适合)。

下面是一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//open file in binary mode
std::fstream file( filename, std::ios::in|::std::ios::binary );
if( !file ) return NULL;

//read the size...
file.seekg(0, std::ios::end);
size_t length = (size_t)file.tellg();
file.seekg(0, std::ios::beg);

//read into memory buffer, then close it.
char *filebuf = new char[length+1];
file.read(filebuf, length);
filebuf[length] = '\\0'; //make it null-terminated
file.close();

如果需要，可以将流环绕在该缓冲区周围，以便更方便地访问，如下所示：

1	std::istrstream header(&filebuf[0], length);

此外，如果您控制文件，请考虑使用平面二进制数据格式而不是文本。读写更可靠，因为你不必处理空白区的所有含糊不清之处。它也更小，解析速度更快。

顺便说一下，C++版本的行计数比Python版本的计数大的原因是，当试图读取EOF时，EOF标记只被设置。所以正确的循环应该是：

1
2
3
4
5
6

while (cin) {
getline(cin, input_line);

if (!cin.eof())
line_count++;
};

相关讨论

以下代码对我来说比这里发布的其他代码快：(Visual Studio 2013，64位500 MB文件，行长一致，格式为[0，1000])。

1
2
3
4
5
6
7

const int buffer_size = 500 * 1024; // Too large/small buffer is not good.
std::vector<char> buffer(buffer_size);
int size;
while ((size = fread(buffer.data(), sizeof(char), buffer_size, stdin)) > 0) {
line_count += count_if(buffer.begin(), buffer.begin() + size, [](char ch) { return ch == '\
'; });
}

它比我所有的python尝试都快了一倍多。

相关讨论

在第二个示例中(使用scanf())原因可能是scanf("%s")解析字符串并查找任何空格字符(space、tab、newline)。

另外，是的，cpython做了一些缓存以避免硬盘读取。

答案的第一个要素是：很慢。该死的慢。我使用scanf获得了巨大的性能提升，如下所示，但它仍然比python慢两倍。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#include <iostream>
#include <time.h>
#include <cstdio>

using namespace std;

int main() {
char buffer[10000];
long line_count = 0;
time_t start = time(NULL);
int sec;
int lps;

int read = 1;
while(read > 0) {
read = scanf("%s", buffer);
line_count++;
};
sec = (int) time(NULL) - start;
line_count--;
cerr <<"Saw" << line_count <<" lines in" << sec <<" seconds." ;
if (sec > 0) {
lps = line_count / sec;
cerr <<" Crunch speed:" << lps << endl;
}
else
cerr << endl;
return 0;
}

相关讨论

好吧，我看到在你的第二个解决方案中，你从cin转到scanf，这是我第一个建议(cin是slooooooooooooow)。现在，如果您从EDCOX1的1度切换到EDCOX1(16)，您将看到性能的另一个提升：EDCOX1×16Ω是用于字符串输入的最快的C++函数。

顺便说一句，不知道同步的事，很好。但你还是应该试试fgets。

相关讨论