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

Question

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

---

（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线文件在一个快速磁盘上。以下是几种解决方案/方法的比较：

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

Answer 1

我落后了几年，但是：

在原始帖子的“编辑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”的影响。（如果我是兰德尔·施瓦茨，这可能会为你赢得一个'Useless Use Of Cat'奖项。

更好的结构是：

$ /usr/bin/time program_to_benchmark < big_file

在这个语句中，打开大文件的是shell，将其作为已经打开的文件描述符传递给程序（实际上，传递给“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}u compression}u 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

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

不过，我预计你还是可以测量“cat file”和“wc-l<；file”之间的差异，并找到一个明显的（2位数的百分比）差异。每一个较慢的测试都将在绝对时间内支付类似的罚款；然而，这将相当于其较大的总时间的一小部分。

事实上，我在Linux3.13（Ubuntu14.04）系统上用一个1.5GB的垃圾文件做了一些快速测试，得到了这些结果（这些结果实际上是“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)

注意，这两个管道结果声称占用了比realtime更多的CPU时间（user+sys）。这是因为我正在使用shell（Bash）的内置“time”命令，它可以识别管道；我在一台多核机器上，管道中的不同进程可以使用不同的核心，累积CPU时间的速度快于实时。使用/usr/bin/time，我看到的CPU时间比realtime小——这表明它只能在命令行上计时传递给它的单个管道元素。另外，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”结果打折扣。

Answer 2

默认情况下，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函数一次读取每个字符。不幸的是，这会带来很多开销。对于少量的输入，这不是一个大问题，但是当您读取数百万行时，性能损失是非常大的。

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

Answer 3

出于好奇，我查看了引擎盖下的情况，并在每次测试中使用了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