提问



我想比较使用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 操作系统  X  v  v10.6.8(Snow  Leopard)和Linux 2.6.32(Red Hat Linux 6.2)下都尝试了这一点。前者是MacBook Pro,后者是一个非常强大的服务器,而不是太过贴切。


修改2: (删除此修改,不再适用)


$ 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


编辑3:


好吧,我试过J.N.的建议,试着让Python存储行读取:但它对python的速度没有任何影响。


我也试过JN建议使用scanfchar数组而不是getlinestd::string。宾果!这导致了Python和C ++的等效性能。 (3,333,333 LPS带有我的输入数据,顺便说一下,每行只有三个字段的短行,通常大约20个字符宽,但有时更多)。


码:


char input_a[512];
char input_b[32];
char input_c[512];
while(scanf("%s %s %s\n", input_a, input_b, input_c) != EOF) {
    line_count++;
};


速度:


$ cat test_lines | ./readline_test_cpp2
Read 10000000 lines in 3 seconds. LPS: 3333333
$ cat test_lines | ./readline_test2.py
Read 10000000 lines in 3 seconds. LPS: 3333333


(是的,我跑了好几次。)所以,我想我现在会用scanf代替getline。但是,如果人们认为std::string/getline的表现受到典型和合理的影响,我仍然很好奇。


编辑4(是:最终编辑/解决方案):


添加:


cin.sync_with_stdio(false);


紧接在我原来的while循环之上导致代码运行得比Python快。


新的性能比较(这是在我的2011 MacBook Pro上),使用原始代码,禁用同步的原始代码和原始Python代码,分别在具有20M行文本的文件上。是的,我运行了几次以消除磁盘缓存混乱。


$ /usr/bin/time cat test_lines_double | ./readline_test_cpp
       33.30 real         0.04 user         0.74 sys
Read 20000001 lines in 33 seconds. LPS: 606060
$ /usr/bin/time cat test_lines_double | ./readline_test_cpp1b
        3.79 real         0.01 user         0.50 sys
Read 20000000 lines in 4 seconds. LPS: 5000000
$ /usr/bin/time cat test_lines_double | ./readline_test.py
        6.88 real         0.01 user         0.38 sys
Read 20000000 lines in 6 seconds. LPS: 3333333


感谢@Vaughn Cato的回答! 人们可以做出的任何详细说明或者很好的参考,人们可以指出为什么这种同步发生,它意味着什么,什么时候它有用,什么时候禁用它将会受到后代的极大赞赏。 :-)


编辑5/更好的解决方案:


正如下面的Gandalf The Gray所建议的,gets甚至比scanf或不同步cin方法更快。我还了解到scanfgets都是UNSAFE,由于缓冲区溢出的可能性,不应该使用它们。所以,我使用fgets编写了这个迭代,这是get的更安全的替代方法。以下是我的同伴们的相关内容:[84] [85]


char input_line[MAX_LINE];
char *result;

//<snip>

while((result = fgets(input_line, MAX_LINE, stdin )) != NULL)
    line_count++;
if (ferror(stdin))
    perror("Error reading stdin.");


现在,这里是使用更大的文件(100M行; ~3.4  GB)在具有非常快的磁盘的快速服务器上的结果,比较Python代码,不同步cinfgets方法,以及与wc实用程序的比较。 [[scanf版本细分出现故障,我不想对其进行故障排除。]]:


$ /usr/bin/time cat temp_big_file | readline_test.py
0.03user 2.04system 0:28.06elapsed 7%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 28 seconds. LPS: 3571428

$ /usr/bin/time cat temp_big_file | readline_test_unsync_cin
0.03user 1.64system 0:08.10elapsed 20%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 8 seconds. LPS: 12500000

$ /usr/bin/time cat temp_big_file | readline_test_fgets
0.00user 0.93system 0:07.01elapsed 13%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 7 seconds. LPS: 14285714

$ /usr/bin/time cat temp_big_file | wc -l
0.01user 1.34system 0:01.83elapsed 74%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
100000000


Recap (lines per second):
python:         3,571,428
cin (no sync): 12,500,000
fgets:         14,285,714
wc:            54,644,808


正如你所看到的,fgets更好,但距离wc性能还很远;我很确定这是因为wc检查每个字符而没有任何内存复制。我怀疑,此时,代码的其他部分将成为瓶颈,所以我不认为优化到那个级别会甚至是值得的,即使可能(因为,毕竟,我实际上需要将读取行存储在内存中)。


还要注意,使用char *缓冲区和fgets与非同步cin到字符串的小额权衡是后者可以读取任意长度的行,而前者需要将输入限制为某些有限数。实际上,这对于读取大多数基于行的输入文件来说可能不是问题,因为缓冲区可以设置为非常大的值,有效输入不会超过该值。


这是教育性的。感谢大家的意见和建议。


编辑6:


正如J.F.Sebastian在下面的评论中所建议的那样,GNU wc实用程序使用普通的C read()(在safe-read.c包装器中)一次读取块(16k字节)并计算新行。这是一个基于J.F.代码的Python等价物(仅显示替换Python for循环的相关代码段:


BUFFER_SIZE = 16384
count = sum(chunk.count('\n') for chunk in iter(partial(sys.stdin.read, BUFFER_SIZE), ''))


这个版本的性能非常快(当然,它仍然比原始的C wc实用程序慢一点):


$ /usr/bin/time cat temp_big_file | readline_test3.py
0.01user 1.16system 0:04.74elapsed 24%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 4.7275 seconds. LPS: 21152829


同样,对于我来说,比较C ++ fgets/cin和第一个python代码与wc -l以及最后一个Python代码段相比,对我来说有点愚蠢两个人实际上并不存储阅读线,而只是计算换行符。尽管如此,探索所有不同的实现并考虑性能影响仍然很有趣。再次感谢!


编辑7:微小的基准附录和回顾


为了完整起见,我想我会用原始(同步的)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

最佳参考


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


std::ios_base::sync_with_stdio(false);


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


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


如果cin读取的输入比实际需要的多,那么第二个整数值将不能用于scanf函数,它具有自己独立的缓冲区。这将导致意外的结果。


为避免这种情况,默认情况下,流与stdio同步。实现这一目标的一种常见方法是cin使用stdio函数根据需要一次一个地读取每个字符。不幸的是,这引入了很多开销。对于少量输入,这不是一个大问题,但是当您阅读数百万行时,性能损失是显着的。


幸运的是,图书馆设计师决定,如果你知道自己在做什么,你也应该能够禁用这个功能以提高性能,所以他们提供了sync_with_stdio方法。[86]

其它参考1


出于好奇,我已经看过引擎盖下发生了什么,我在每次测试中都使用了dtruss/strace。[87]


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

其它参考2


我在这里落后了几年,但是:


在原帖的编辑4/5/6中,您正在使用构造:


$ /usr/bin/time cat big_file | program_to_benchmark


这有两种不同的方式:



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

  2. 使用猫是不必要的,实际上适得其反;你正在添加移动部件。如果你使用的是一个足够旧的系统(即使用单个CPU并且 - 在某些代数的计算机中 - I/O比CPU快) - 仅仅cat运行的事实就可以了你也可以接受任何输入和输出缓冲以及其他处理`cat`可能做的事情。(如果我是Randal Schwartz,这可能会让你获得无用的猫奖。[88]



更好的结构是:


$ /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`)

  • 在实践中,在现代机器上,管道中添加的猫可能没有实际后果



但我有点犹豫地说最后一件事。如果我们检查编辑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()系统调用(或等效),它从磁盘(实际上是缓冲区缓存)传输文件,以及管道写入将它们传递给`wc`。正确的测试仍然必须执行read()调用;只保存了write-to-pipe和read-from-pipe调用,而且这些调用应该相当便宜。


不过,我预测你可以衡量`cat file |之间的区别wc -l`和`wc -l< file`并找到一个明显的(2位数百分比)差异。每个较慢的测试都会在绝对时间内付出类似的代价;然而,这将占其较长总时间的较小部分。


事实上,我在Linux 3.13(Ubuntu 14.04)系统上使用1.5千兆字节的垃圾文件做了一些快速测试,获得了这些结果(这些实际上是最好的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时间(用户+ sys)比实时多。这是因为我使用shell(Bash)的内置时间命令,它认识到了管道;我在多核机器上,管道中的单独进程可以使用单独的内核,比实时更快地累积CPU时间。使用/usr/bin/time我看到比实时更短的CPU时间 - 表明它只能是时间单个管道元素在其命令行上传递给它。另外,shell的输出给出毫秒,而/usr/bin/time只给出一秒钟的hundreth。


因此,在`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()。所以在实践中,以两种方式运行基准测试可能会很好;或许用一些小因素来折扣猫结果,以原谅运行猫本身的成本。

其它参考3


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


while循环之前将以下语句添加到C ++版本使其与Python版本内联:[89]


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


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

其它参考4


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);


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

其它参考5


顺便说一句,C ++版本的行数大于Python版本的计数的原因是eof标志仅在尝试读取超出eof时才设置。所以正确的循环是:


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

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

其它参考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


在你的第二个例子中(使用scanf()),为什么这仍然较慢可能是因为scanf(%s)解析字符串并查找任何空格char(空格,制表符,换行符)。


此外,是的,CPython做了一些缓存以避免硬盘读取。

其它参考8


答案的第一个要素:<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;
}

其它参考9


好吧,我看到你在第二个解决方案中从cin切换到scanf,这是我要给你的第一个建议(cin是sloooooooooooow)。现在,如果你从scanf切换到fgets,你会看到性能的另一个提升:fgets是字符串输入最快的C ++函数。


BTW,不知道那个同步的事情,很好。但是你仍然应该尝试fgets