为啥在 C++ 中从标准输入读取行比 Python 慢得多？
Posted
技术标签:
【中文标题】为啥在 C++ 中从标准输入读取行比 Python 慢得多？【英文标题】：Why is reading lines from stdin much slower in C++ than Python?为什么在 C++ 中从标准输入读取行比 Python 慢得多？ 【发布时间】：2012-03-11 09:22:02 【问题描述】：我想比较使用 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 行文件。这是比较，有几种解决方案/方法：
| 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 |
【问题讨论】：
您是否多次运行测试？可能是磁盘缓存问题。 @VaughnCato 是的，在两台不同的机器上也是如此。 问题在于与 stdio 的同步 -- 请参阅我的回答。 因为似乎没有人提到为什么你会在 C++ 中多出一行：不要针对cin.eof() 进行测试！ 将 getline 调用放入 'if`声明。
wc -l 速度很快，因为它一次读取多行流（可能是fread(stdin)/memchr('\n') 组合）。 Python 结果的数量级相同，例如wc-l.py
【参考方案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 方法。
【讨论】：
这应该在顶部。这几乎肯定是正确的。答案不能在于用fscanf 调用替换读取，因为这根本没有Python 做的那么多工作。 Python 必须为字符串分配内存，可能会多次分配内存，因为现有的分配被认为是不充分的——就像 C++ 的 std::string 方法一样。这项任务几乎可以肯定是 I/O 绑定的，而且关于在 C++ 中创建 std::string 对象或在其本身中使用 <iostream> 的成本有太多的 FUD。
是的，在我原来的 while 循环正上方添加这一行可以加速代码甚至超过 python。我即将发布结果作为最终编辑。再次感谢！
请注意sync_with_stdio() 是一个静态成员函数，并且在任何流对象（例如cin）上调用此函数可以打开或关闭all 标准的同步iostream 对象。【参考方案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，而不是您的基准。 time 显示的“用户”和“系统”CPU 使用率是 cat 的，而不是您的基准测试程序。更糟糕的是，“真实”时间也不一定准确。根据cat 和本地操作系统中管道的实现，cat 可能会写入一个最终的巨型缓冲区并在读取器进程完成其工作之前很久就退出。
使用cat 是不必要的，实际上会适得其反；您正在添加移动部件。如果您在一个足够旧的系统上（即使用单个 CPU 并且 - 在某些代计算机中 - I/O 比 CPU 快） - cat 正在运行的事实可能会大大影响结果。您还受制于cat 可能进行的任何输入和输出缓冲以及其他处理。 （如果我是 Randal Schwartz，这可能会为您赢得 'Useless Use Of Cat' 奖。
更好的结构是：
$ /usr/bin/time program_to_benchmark < big_file
在此语句中，shell 打开 big_file，将其作为已打开的文件描述符传递给您的程序（嗯，实际上是 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 -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() 调用；只有 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 = 2.768，或者 CPU 使用率高达 177%！在我的随机它当时就在那里的测试盒上。
我应该补充一点，这些测试风格之间至少还有另一个显着差异，我不能说这是有利还是错误；你必须自己决定：
当您运行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 本身的成本。
【讨论】：
哇，这真是太有见地了！虽然我知道 cat 对于向程序的标准输入提供输入是不必要的，并且 重定向是在早期阶段从 shell 命令行中解析出来的，如果它提供了从左到右流的更令人愉悦的外观，则允许您执行其中之一：$ < big_file time my_program@ 987654364@ 这应该可以在任何 POSIX shell 中工作（即不是 `csh`，我不确定像 `rc` 之类的异国情调：）【参考方案4】：
我在 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 秒。
【讨论】：
我也会避免在堆栈上设置一个 1MB 的缓冲区。它可能导致 ***（尽管我想这是一个讨论它的好地方！） Matthieu，Mac 默认使用 8MB 的进程堆栈。 Linux 默认每个线程使用 4MB，IIRC。对于以相对较浅的堆栈深度转换输入的程序来说，1MB 并不是什么大问题。更重要的是，如果缓冲区超出范围，std::cin 将丢弃堆栈。 @SEK Windows 默认堆栈大小为 1MB。【参考方案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] = '\0'; //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 == '\n'; );
它比我所有的 Python 尝试都高出 2 倍以上。
【讨论】：
【参考方案7】：顺便说一句，C++ 版本的行数比 Python 版本的行数多 1 的原因是，只有在尝试读取超出 eof 的内容时才会设置 eof 标志。所以正确的循环是：
while (cin)
getline(cin, input_line);
if (!cin.eof())
line_count++;
;
【讨论】：
真正正确的循环是：while (getline(cin, input_line)) line_count++;【参考方案8】：
在您的第二个示例（使用scanf()）中，速度仍然较慢的原因可能是因为scanf("%s") 解析字符串并查找任何空格字符（空格、制表符、换行符）。
另外，是的，CPython 会进行一些缓存以避免硬盘读取。
【讨论】：
【参考方案9】：好吧，我看到在您的第二个解决方案中，您从 cin 切换到 scanf，这是我要给您的第一个建议（cin 是 slooooooooooooow）。现在，如果您从scanf 切换到fgets，您会看到性能的另一个提升：fgets 是最快的 C++ 字符串输入函数。
顺便说一句，不知道同步的事情，很好。但是你还是应该试试fgets。
【讨论】：
【参考方案10】：答案的第一个元素：<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;
【讨论】：
以上是关于为啥在 C++ 中从标准输入读取行比 Python 慢得多？的主要内容，如果未能解决你的问题，请参考以下文章