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

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

#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;
}

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

默认情况下，它与 stdio 同步，这会导致它避免任何输入缓冲。如果将它添加到主节点的顶部，则应该会看到更好的性能：cin

std::ios_base::sync_with_stdio(false);

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

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

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

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

幸运的是，库设计人员认为，如果您知道自己在做什么，也应该能够禁用此功能以提高性能，因此他们提供了sync_with_stdio方法。从此链接（强调后加）：

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

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

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

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

在循环之前将以下语句添加到 C++ 版本，使其与 Python 版本内联：while

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

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

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

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

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

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

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

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

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

蟒

./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

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] = '\0'; //make it null-terminated
file.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. 您实际上是在计时执行，而不是您的基准测试。显示的 'user' 和 'sys' CPU 使用率是 的 ，而不是基准测试程序。更糟糕的是，“实时”时间也不一定准确。根据本地操作系统中管道的实现和管道的实现，可能会写入最终的巨型缓冲区，并在读取器进程完成其工作之前很久就退出。cattimecatcatcat

2. 使用是不必要的，实际上适得其反;您正在添加活动部件。如果你在一个足够老的系统上（即使用单个CPU，并且--在某些代的计算机中--I/O比CPU快），那么仅仅是运行的事实就可以大大影响结果。您还受到任何输入和输出缓冲以及其他处理可能执行的操作。 （如果我是 Randal Schwartz，这可能会为您赢得“无用的猫”奖。catcatcat

更好的结构是：

$ /usr/bin/time program_to_benchmark < big_file

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

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

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

$ 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 重定向功能不完全满意的人来说，它们更“自然”

• 在某些情况下，可能需要（例如：要读取的文件需要某种权限才能访问，并且您不希望将该权限授予要进行基准测试的程序：catsudo 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 ...

-- 这声称在测试期间消耗了 74% 的 CPU;事实上，1.34/1.83 大约是 74%。也许是一连串：cat

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

本来只需要剩下的 .49 秒！可能不是：这里必须支付从“磁盘”（实际上是缓冲区缓存）传输文件的系统调用（或等效调用），以及将它们传送到的管道写入。正确的测试仍然需要执行这些调用;只有 write-to-pipe 和 read-from-pipe 调用会被保存，而且这些调用应该非常便宜。catread()wcread()

不过，我预测您将能够测量 和 之间的差异并找到明显的（2 位百分比）差异。每个较慢的测试都会在绝对时间内付出类似的代价;然而，这仅占其较大总时间的一小部分。cat file | wc -lwc -l < file

事实上，我在 Linux 3.13 （Ubuntu 14.04） 系统上用一个 1.5 GB 的垃圾文件做了一些快速测试，获得了这些结果（这些实际上是“三局两胜”的结果;当然，在启动缓存之后）：

$ 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 时间的速度比实时更快。使用我看到的 CPU 时间比实时时间小 -- 表明它只能在其命令行上对传递给它的单个管道元素进行计时。此外，shell 的输出提供毫秒，而只提供百分之一秒。/usr/bin/time/usr/bin/time

因此，在效率水平上，产生了巨大的差异：409 / 283 = 1.453 或 45.3% 的实时性，而 775 / 280 = 2.768，或使用的 CPU 增加了 177%！在我的随机测试盒上，它当时就在那里。wc -lcat

我应该补充一点，这些测试风格之间至少还有一个其他显着差异，我不能说这是好处还是缺点;你必须自己决定：

当您运行 时，您的程序正在接收来自管道的输入，其速度恰好与 发送的速度相同，并且块不大于 由 写入的块。cat big_file | /usr/bin/time my_programcatcat

当您运行时，您的程序会收到实际文件的打开文件描述符。您的程序（或在许多情况下，编写它所用语言的 I/O 库）在显示引用常规文件的文件描述符时可能会采取不同的操作。它可用于将输入文件映射到其地址空间，而不是使用显式系统调用。这些差异对基准测试结果的影响可能比运行二进制文件的小成本大得多。/usr/bin/time my_program < big_filemmap(2)read(2)cat

当然，如果同一程序在两种情况下的性能明显不同，这是一个有趣的基准结果。它表明，程序或其 I/O 库确实在做一些有趣的事情，比如使用 .因此，在实践中，双向运行基准测试可能是件好事;也许通过一些小因素来打折结果，以“原谅”运行本身的成本。mmap()catcat