为什么在C++中从标准输入读取行比Python慢得多？

答案的第一个元素：<iostream>很慢。该死的慢。如下所示，我通过scanf获得了巨大的性能提升，但它仍然比Python慢两倍。

#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;}elsecerr << endl;return 0;}

tl； dr：因为C++的默认设置不同，需要更多的系统调用。

默认情况下，cin与标准输入输出同步，这导致它避免任何输入缓冲。如果您将其添加到主程序的顶部，您应该会看到更好的性能：

std::ios_base::sync_with_stdio(false);

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

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

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

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

幸运的是，库设计者决定，如果您知道自己在做什么，您也应该能够禁用此功能以获得更高的性能，因此他们提供了#0方法。从这个链接（强调是添加的）：

如果同步关闭，则允许C++标准流独立缓冲其I/O，在某些情况下可能会更快。

在您的第二个示例（使用scanf()）中，这仍然较慢的原因可能是因为scanf("%s")解析字符串并查找任何空格字符（空格、制表符、换行符）。

此外，是的，CPython做了一些缓存来避免硬盘读取。

我在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秒。

好吧，我看到在你的第二个解决方案中，你从cin切换到scanf，这是我要给你的第一个建议（cin是slooooooooow）。现在，如果你从scanf切换到fgets，你会看到性能的另一个提升：fgets是字符串输入最快的C++函数。

顺便说一句，不知道同步的事情，很好。但你仍然应该尝试fgets。

顺便说一句，C++版本的行数比Python版本的行数大1的原因是eof标志仅在尝试读取超出eof时才会设置。所以正确的循环是：

while (cin) {getline(cin, input_line);
if (!cin.eof())line_count++;};

只是出于好奇，我看了看引擎盖下发生了什么，我在每次测试中都使用了dtruss/strace。

C++

./a.out < inSaw 6512403 lines in 8 seconds.  Crunch speed: 814050

syscallssudo dtruss -c ./a.out < in

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

python

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

syscallssudo dtruss -c ./a.py < in

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

如果您不关心文件加载时间或加载小文本文件，流运算符scanf可能很方便。但是，如果您关心性能，您应该将整个文件缓冲到内存中（假设它适合）。

这里有一个例子：

//open file in binary modestd::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-terminatedfile.close();

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

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

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

到目前为止，以下代码对我来说比发布在这里的其他代码更快：（Visual Studio 2013,64位，500 MB文件，行长统一在[0,1000）中）。

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 == '\n'; });}

它比我所有的Python尝试都要多2倍。

我在这里落后了几年，但是：

在原始帖子的“编辑4/5/6”中，您使用的结构：

$ /usr/bin/time cat big_file | program_to_benchmark

这在几个不同的方面是错误的：

1. 您实际上是在计时cat的执行，而不是您的基准测试。time显示的“用户”和“系统”CPU使用率是cat的使用率，而不是您的基准测试程序。更糟糕的是，“真实”时间也不一定准确。根据cat和本地操作系统中管道的实现，cat可能会在读取器进程完成工作之前很久写入一个最终的巨大缓冲区并退出。

2. 使用cat是不必要的，实际上适得其反；你在添加移动部件。如果你在一个足够旧的系统上（即只有一个CPU，并且在某些代的计算机中，I/O比CPU快）--仅仅是cat运行的事实就会大大影响结果。你还受到输入和输出缓冲以及cat可能做的其他处理的影响。（如果我是兰德尔·施瓦茨，这可能会为你赢得'Useless use Of Cat'奖。

更好的结构是：

$ /usr/bin/time program_to_benchmark < big_file

在这个语句中，是shell打开big_file，将其作为已经打开的文件描述符传递给您的程序（实际上是time，然后time将您的程序作为子进程执行）。100%的文件读取严格由您尝试基准测试的程序负责。这可以让您真正了解其性能，而不会出现虚假的并发症。

我会提到两个可能的，但实际上是错误的，也可以考虑的“修复”（但我对它们进行了不同的“编号”，因为这些不是原始帖子中错误的东西）：

A.你可以通过只计时你的程序来“修复”这个问题：

$ cat big_file | /usr/bin/time program_to_benchmark

B.或通过对整个管道进行计时：

$ /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可能没有真正的后果。

但是我说最后一件事有些犹豫。如果我们检查'Edit 5'中的最后一个结果-

$ /usr/bin/time cat temp_big_file | wc -l0.01user 1.34system 0:01.83elapsed 74%CPU ...

--这声称cat在测试期间消耗了74%的CPU；实际上1.34/1.83大约是74%。也许是一次运行：

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

可能不会：这里的cat必须支付read()系统调用（或等效调用），这些调用将文件从“磁盘”（实际上是缓冲区缓存）传输到wc，以及管道写入以将它们传递到wc。正确的测试仍然必须执行那些read()调用；只有写入管道和从管道读取调用会被保存，这些应该非常便宜。

尽管如此，我还是预测你能够测量cat file | wc -l和wc -l < file之间的差异，并找到一个明显的（2位数百分比）差异。每一个较慢的测试都会在绝对时间上付出类似的代价；然而，这相当于其较大的总时间的一小部分。

事实上，我在Linux3.13（Ubuntu 14.04）系统上用1.5 GB的垃圾文件做了一些快速测试，获得了这些结果（这些实际上是“3中最好的”结果；当然，在启动缓存之后）：

$ time wc -l < /tmp/junkreal 0.280s user 0.156s sys 0.124s (total cpu 0.280s)$ time cat /tmp/junk | wc -lreal 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 < big_file时，您的程序会收到一个指向实际文件的打开文件描述符。您的程序-在许多情况下是编写它的语言的I/O库-在出现引用常规文件的文件描述符时可能会采取不同的操作。它可能会使用mmap(2)将输入文件映射到其地址空间，而不是使用显式的read(2)系统调用。这些差异对您的基准测试结果的影响可能比运行cat二进制文件的小成本要大得多。

当然，如果同一程序在这两种情况下的表现明显不同，这是一个有趣的基准测试结果。它表明，确实，该程序或其I/O库是做了一些有趣的事情，比如使用mmap()。因此，在实践中，两种方式运行基准测试可能是好的；也许可以将cat的结果贴现一些小因素，以“原谅”运行cat本身的成本。