题 为什么在C ++中读取stdin的行比Python要慢得多?


我想比较使用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 OS X 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的速度没有任何影响。

我也尝试过J.N.的使用建议 scanf 变成一个 char 数组而不是 getline 变成一个 std::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 做法。我也学到了 scanf 和 gets 都是UNSAFE,由于缓冲区溢出的可能性,不应该使用它。所以,我用这个迭代编写了 fgets,获得更安全的替代方案。以下是我的同伴们的相关内容:

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代码,不同步 cin,和 fgets方法,以及与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检查每个字符而没有任何内存复制。我怀疑,在这一点上,代码的其他部分将成为瓶颈,所以我不认为优化到那个级别甚至是值得的,即使可能(因为,毕竟,我实际上需要存储读取线在记忆中)。

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

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

编辑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

1465
2018-02-21 03:24


起源


你多次运行测试了吗?也许存在磁盘缓存问题。 - Vaughn Cato
@JJC:我看到两种可能性(假设你已经删除了David提出的缓存问题):1) <iostream> 表现很糟糕。这不是第一次发生。 2)Python非常聪明,不会在for循环中复制数据,因为你没有使用它。您可以重新测试尝试使用 scanf 和a char[]。或者,您可以尝试重写循环,以便使用字符串完成某些操作(例如,保留第5个字母并将其连接到结果中)。 - J.N.
问题是与stdio同步 - 请参阅我的回答。 - Vaughn Cato
因为似乎没有人提到你为什么要用C ++获得额外的一行: 不要测试 cin.eof()! 放在 getline 调用'if`语句。 - Xeo
wc -l 很快,因为它一次读取多行(可能是 fread(stdin)/memchr('\n') 组合)。 Python结果的数量级相同,例如: wc-l.py - jfs


答案:


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

std::ios_base::sync_with_stdio(false);

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

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

如果读取更多输入 cin 比实际需要的那样,第二个整数值将不可用 scanf function,有自己独立的缓冲区。这将导致意想不到的结果。

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

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


1286
2018-03-11 18:10



这应该在顶部。这几乎肯定是正确的。答案不在于用一个替换读取 fscanf 调用,因为它完全不像Python那样做很多工作。 Python必须为字符串分配内存,可能需要多次,因为现有的分配被认为是不合适的 - 就像C ++方法一样 std::string。这个任务几乎肯定是I / O绑定的,并且有很多关于创建成本的FUD std::string C ++中的对象或使用 <iostream> 在其本身。 - Karl Knechtel
是的,在我的原始循环上方添加此行,同时循环加速代码甚至超过python。我即将发布结果作为最终编辑。再次感谢! - JJC
是的,这实际上也适用于cout,cerr和clog。 - Vaughn Cato
为了使cout,cin,cerr和clog更快,这样做std :: ios_base :: sync_with_stdio(false); - 01100110
注意 sync_with_stdio() 是一个静态成员函数,并在任何流对象上调用此函数(例如 cin)打开或关闭同步 所有 标准的iostream对象。 - John Zwinck


出于好奇,我已经看过引擎盖下发生了什么,我已经习惯了 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

蟒蛇

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

115
2018-02-21 03:33





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

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

$ /usr/bin/time cat big_file | program_to_benchmark

这有两种不同的方式:

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

  2. 使用“猫”是不必要的,实际上适得其反;你正在添加移动部件。如果你使用的是一个足够旧的系统(即使用单个CPU并且 - 在某些代码的计算机中 - I / O比CPU快) - “cat”运行的这一事实可能会对结果产生很大的影响。你也受到任何输入和输出缓冲以及其他处理`cat`的影响。 (这可能会让你获得一个 '无用的猫' 如果我是兰德尔施瓦茨,我会获奖。

更好的结构是:

$ /usr/bin/time program_to_benchmark < big_file

在这个声明中它是 贝壳 打开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重定向工具不太满意的人来说,它们更“自然”

  • 可能有“猫”的情况  需要(例如:要读取的文件需要某种权限才能访问,并且您不希望将该权限授予要进行基准测试的程序:`sudo cat / dev / sda | / usr / bin / time my_compression_test - 无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()系统调用(或等效),它从'disk'(实际上是缓冲区缓存)传输文件,以及管道写入将它们传递给`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)的内置'time'命令,它可以识别管道;我在多核机器上,管道中的单独进程可以使用单独的内核,比实时更快地累积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()。所以在实践中,以两种方式运行基准测试可能会很好;或许用一些小因素来折扣“猫”结果,以“原谅”运行“猫”本身的成本。


79
2018-03-13 23:04



哇,这很有见地!虽然我已经意识到cat不需要将输入提供给程序的stdin,并且<shell重定向是首选,但由于前一种方法在视觉上保留了从左到右的数据流,我通常会坚持使用cat。当我推理管道时。在我发现这种情况下的性能差异可以忽略不计。但是,我非常感谢你教育我们,贝拉。 - JJC
我个人会避免提及,因为这并没有解决原始问题(注意在竞争的例子中使用cat是不变的)。但是,再次感谢有关* nix的来龙去脉的知识分子讨论。 - JJC
重定向在早期阶段从shell命令行解析出来,如果它给出了从左到右流程更令人满意的外观,则允许您执行其中一个操作: $ < big_file time my_program  $ time < big_file my_program  这应该适用于任何POSIX shell(即不是`csh`,我不确定exotica如`rc` :) - Bela Lubkin
同样,除了由于同时运行`cat`二进制文件而可能无趣的增量性能差异之外,您放弃了被测程序能够mmap()输入文件的可能性。这可能会对结果产生深远的影响。即使你自己用各种语言编写基准测试,只使用他们的“文件输入行”成语,这也是如此。这取决于各种I / O库的详细工作方式。 - Bela Lubkin
不要忘记你仍然可以通过重定向从左到右做: <file program 做几乎相同的事情(JJC提到的警告) cat file | program。 - Justin C. B.


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

将以下语句添加到C ++版本之前 while 循环使其与内联 蟒蛇 版:

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

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


75
2018-03-11 16:37



您可能希望尝试不同的缓冲区大小以获取更多有用的信息。我怀疑你会看到快速递减的回报。 - Karl Knechtel
我的回答太匆忙了;将缓冲区大小设置为默认值以外的其他值不会产生明显的差异。 - karunski
我也避免在堆栈上设置1MB缓冲区。它可以导致stackoverflow(虽然我想这是一个讨论它的好地方!) - Matthieu M.
Matthieu,Mac默认使用8MB进程堆栈。 Linux每个线程默认使用4MB,IIRC。对于以相对较浅的堆栈深度转换输入的程序,1MB并不是一个问题。但更重要的是,如果缓冲区超出范围,std :: cin将废弃堆栈。 - SEK
@SEK Windows默认堆栈大小为1MB。 - Étienne


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

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


23
2018-02-21 03:32





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

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

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

11
2018-02-21 03:17



真正正确的循环是: while (getline(cin, input_line)) line_count++; - Jonathan Wakely


以下代码对我来说比到目前为止发布的其他代码更快: (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倍。


8
2018-02-22 02:33





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

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


7





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

6



在我做了第三次编辑之前没有看到这篇文章,但再次感谢你的建议。奇怪的是,现在使用上面edit3中的scanf行,对我来说没有2x命中率。顺便说一下,我正在使用2.7。 - JJC
修复c ++版本后,这个stdio版本比我计算机上的c ++ iostreams版本慢得多。 (3秒vs 1秒) - karunski
同样在这里。同步到stdio是诀窍。 - J.N.
fgets甚至更快;请参阅上面的编辑5。谢谢。 - JJC