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

Question

我想比较使用 Python 和 C++ 从标准输入读取字符串输入的行，并震惊地看到我的 C++ 代码运行速度比等效的 Python 代码慢一个数量级。由于我的 C++ 生锈了，而且我还不是 Python 专家，请告诉我我做错了什么或者我误解了什么。

---

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

执行每秒行数蟒蛇（默认） 3,571,428 cin （默认/天真） 819,672 cin（不同步） 12,500,000 fgets 14,285,714 wc（不公平比较） 54,644,808

原文由 JJC 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

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

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

 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， 这在某些情况下可能会快得多。

原文由 Vaughn Cato 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

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

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

 $ /usr/bin/time cat big_file | program_to_benchmark

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

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

2. 使用 cat 是不必要的，实际上会适得其反；您正在添加移动部件。如果你在一个足够老的系统上（即只有一个 CPU，并且——在某些代的计算机中——I/O 比 CPU 快）——仅仅 cat 正在运行的事实就可以显着地影响结果。您还受制于任何输入和输出缓冲以及其他处理 cat 可能会做的事情。 （如果我是 Randal Schwartz，这可能会为你赢得 “无用的猫” 奖。

更好的结构是：

 $ /usr/bin/time program_to_benchmark < big_file

在此语句中，它是打开 big_file 的 shell ，将其作为已打开的文件描述符传递给您的程序（嗯，实际上是 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 可能没有实际意义。

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

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

-- 这声称 cat 在测试期间消耗了 74% 的 CPU；实际上 1.³⁴⁄₁.83 大约是 74%。也许是：

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

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

不过，我预测您将能够测量 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 = 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 本身的成本。

原文由 Bela Lubkin 发布，翻译遵循 CC BY-SA 4.0 许可协议