为什么在 C++ 中从 stdin 读取行比在 Python 中慢得多？-IT科技

摘要：问题描述：我想比较一下使用 Python 和 C++ 从 stdin 读取字符串输入行的情况，结果惊讶地发现我的 C++ 代码比等效的 Python 代码运行速度慢了一个数量级。由于我的 C++ 技能生疏，而且我还不是 Pythonista 专家，如果我做错了什么或者误解了什么，请告诉我。（TLDR 答案：包...

问题描述：

我想比较一下使用 Python 和 C++ 从 stdin 读取字符串输入行的情况，结果惊讶地发现我的 C++ 代码比等效的 Python 代码运行速度慢了一个数量级。由于我的 C++ 技能生疏，而且我还不是 Pythonista 专家，如果我做错了什么或者误解了什么，请告诉我。

（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，后者是一台非常强大的服务器，不过这并不是太贴切。

$ 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 行文件。以下是比较，有几种解决方案/方法：

执行	每秒行数
python（默认）	3,571,428
cin（默认/简单）	819,672
cin（无同步）	12,500,000
函数获取	14,285,714
wc（不公平的比较）	54,644,808

解决方案 1：

tl;dr：由于 C++ 中的不同默认设置需要更多的系统调用。

默认情况下，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方法。来自此链接（重点已添加）：

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

解决方案 2：

出于好奇，我查看了内部发生的事情，并在每次测试中使用了dtruss/strace。

C++

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

系统调用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

Python

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

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

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

解决方案 3：

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

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

$ /usr/bin/time cat big_file | program_to_benchmark

这种做法在几个方面都是错误的：

您实际上是在计时的执行时间cat，而不是基准测试时间。显示的“用户”和“系统”CPU 使用率time是的cat，而不是基准测试程序的。更糟糕的是，“实际”时间也不一定准确。根据cat本地操作系统中和管道的实现，可能会cat在读取器进程完成其工作之前很久就写入最终的巨大缓冲区并退出。
使用cat是不必要的，而且实际上适得其反；你正在添加移动部件。如果你的系统足够老旧（即只有一个 CPU，并且——在某些代计算机中—— I/O 比 CPU 快）——cat运行的事实可能会对结果产生重大影响。你还会受到输入和输出缓冲以及其他处理的影响cat。（如果我是 Randal Schwartz，这可能会让你获得“无用使用 Cat”奖。

更好的构造是：

$ /usr/bin/time program_to_benchmark < big_file

在此语句中，shell打开big_file，将其作为已打开的文件描述符传递给您的程序（实际上，time然后将您的程序作为子进程执行）。100% 的文件读取完全由您尝试进行基准测试的程序负责。这可以让您真正了解其性能，而不会产生虚假的复杂性。

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

答：您可以通过只对程序进行计时来“修复”此问题：

$ 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可能没有实际意义。

但我有些犹豫地说最后一句话。如果我们检查“编辑 5”中的最后一个结果——

$ /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%。也许运行：

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

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

不过，我预计您能够测量和之间的差异cat file | wc -l，wc -l < file并发现明显的（两位数百分比）差异。每个较慢的测试在绝对时间上都会付出类似的代价；但这只占其较长总时间的一小部分。

实际上，我在 Linux 3.13（Ubuntu 14.04）系统上对一个 1.5 GB 的垃圾文件进行了一些快速测试，获得了以下结果（这些实际上是“3 个中最好的”结果；当然，是在启动缓存之后）：

$ 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 时间（用户+系统）比实际挂钟时间更多。这是因为我使用的是 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本身的成本。

解决方案 4：

我使用 Mac 上的 g++ 在我的计算机上重现了原始结果。

在循环之前将以下语句添加到 C++ 版本while可使其与Python版本保持一致：

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

sync_with_stdio将速度提高到 2 秒，设置更大的缓冲区将其缩短到 1 秒。

解决方案 5：

getline如果您不关心文件加载时间或加载的是小文本文件，那么流运算符scanf会非常方便。但是，如果您关心的是性能，那么您实际上应该将整个文件缓冲到内存中（假设它能容纳）。

以下是一个例子：

//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] = ''; //make it null-terminated
file.close();

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

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

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

解决方案 6：

对我来说，以下代码比迄今为止在此处发布的其他代码更快：（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 == '
'; });
}

它比我所有的 Python 尝试都好 2 倍以上。

解决方案 7：

顺便说一句，C++ 版本的行数比 Python 版本的行数多 1 的原因是，只有尝试读取 eof 以外的内容时，才会设置 eof 标志。因此，正确的循环应该是：

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

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

解决方案 8：

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

另外，是的，CPython 确实进行了一些缓存以避免硬盘读取。

解决方案 9：

答案的第一个要素是：<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;
    } 
    else
        cerr << endl;
    return 0;
}

解决方案 10：

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

顺便说一句，我不知道同步功能，很好。但你还是应该尝试一下fgets。

解决方案 11：

我参加这个游戏已经很晚了，但我想我还是要说几句：

Python 行：

for line in  sys.stdin:
    count += 1

不从流中读取数据。它仅计算流遇到的行数 -仅此而已。

Peter Mortensen 对 dtruss 的分析有些发现：
https://stackoverflow.com/a/9657502/1043530

注意

read_nocancel                               25958

这不是用 Python 完成的。Python 解释器就像任何其他程序一样，如果它进行 I/O，它将通过 strace 或 dtruss 显示它。

重新执行这个“超快”的 Python 程序并进行实际读取，我相信您会看到 dtruss 输出中的一些变化。是的，我知道我迟到了……但是这个引起了我的注意，因为人们正在谈论禁用这个和那个、fgets、vs 等等……如果程序“A”不执行磁盘 I/O 但程序“B”执行，在很多/大多数/所有情况下，这解释了为什么程序“A”更快。

TLDR：Peter Mortensen dtruss run 证明程序之间的错误等价性，他的帖子应该被标记为答案。

-标记