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

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

$ /usr/bin/time cat big_file | program_to_benchmark

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

你实际上是在给cat的执行计时，而不是基准。按时间显示的“user”和“sys”CPU使用情况是cat的，而不是基准程序。更糟糕的是，“实时”时间也不一定准确。根据cat和本地操作系统中管道的实现，cat可能会在读取器进程完成其工作之前很久写入最后一个巨大缓冲区并退出。使用猫是不必要的，事实上适得其反；您正在添加活动部件。如果您使用的是一个足够旧的系统（即，只有一个CPU，而且在某些代的计算机中，i/O速度比CPU快），那么仅仅是cat在运行这一事实就可以显著地改变结果。你也会受到输入和输出缓冲以及其他处理猫可能做的任何事情的影响。

更好的结构是：

$ /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'

这些都是错误的，原因与第二条相同：他们仍然在不必要地使用cat。我提到它们有几个原因：

对于那些不太熟悉POSIX shell的I/O重定向功能的人来说，它们更“自然”在某些情况下，可能需要cat（例如：要读取的文件需要某种权限才能访问，而您不想将该权限授予要进行基准测试的程序：sudo cat/dev/sda |/usr/bin/time my_compression_test--无输出）实际上，在现代机器上，管道中增加的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（）系统调用（或等效调用）的费用，这些系统调用将文件从“磁盘”（实际上是缓冲缓存）传输，以及管道写入以将文件传递到wc。正确的测试仍然必须执行这些read（）调用；只保存了对管道的写入和从管道读取调用，而且这些调用应该非常便宜。

尽管如此，我预测您将能够测量cat file |wc-l和wc-l<file之间的差异，并找到一个明显的（2位数百分比）差异。每一个速度较慢的测试都将在绝对时间内付出类似的代价；然而，这将相当于其较大总时间的较小部分。

事实上，我在Linux 3.13（Ubuntu 14.04）系统上用一个1.5千兆字节的垃圾文件进行了一些快速测试，获得了这些结果（这些结果实际上是“三选一”的结果；当然，在启动缓存之后）：

$ 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的效率水平上，猫产生了巨大的差异：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）将输入文件映射到其地址空间，而不是使用显式读取（2）系统调用。这些差异对基准测试结果的影响可能远远大于运行cat二进制文件的小成本。

当然，如果同一个程序在两种情况下表现明显不同，这是一个有趣的基准测试结果。它表明，实际上，程序或其I/O库正在做一些有趣的事情，比如使用mmap（）。因此，在实践中，双向运行基准可能会很好；也许，为了“原谅”猫本身的运行成本，可以将猫的结果减去一些小因素。

在第二个示例中（使用scanf（）），速度仍然较慢的原因可能是因为scanf（“%s”）解析字符串并查找任何空格字符（空格、制表符、换行符）。

此外，是的，CPython会进行一些缓存以避免硬盘读取。

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

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

$ /usr/bin/time cat big_file | program_to_benchmark

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

你实际上是在给cat的执行计时，而不是基准。按时间显示的“user”和“sys”CPU使用情况是cat的，而不是基准程序。更糟糕的是，“实时”时间也不一定准确。根据cat和本地操作系统中管道的实现，cat可能会在读取器进程完成其工作之前很久写入最后一个巨大缓冲区并退出。使用猫是不必要的，事实上适得其反；您正在添加活动部件。如果您使用的是一个足够旧的系统（即，只有一个CPU，而且在某些代的计算机中，i/O速度比CPU快），那么仅仅是cat在运行这一事实就可以显著地改变结果。你也会受到输入和输出缓冲以及其他处理猫可能做的任何事情的影响。

更好的结构是：

$ /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'

这些都是错误的，原因与第二条相同：他们仍然在不必要地使用cat。我提到它们有几个原因：

对于那些不太熟悉POSIX shell的I/O重定向功能的人来说，它们更“自然”在某些情况下，可能需要cat（例如：要读取的文件需要某种权限才能访问，而您不想将该权限授予要进行基准测试的程序：sudo cat/dev/sda |/usr/bin/time my_compression_test--无输出）实际上，在现代机器上，管道中增加的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（）系统调用（或等效调用）的费用，这些系统调用将文件从“磁盘”（实际上是缓冲缓存）传输，以及管道写入以将文件传递到wc。正确的测试仍然必须执行这些read（）调用；只保存了对管道的写入和从管道读取调用，而且这些调用应该非常便宜。

尽管如此，我预测您将能够测量cat file |wc-l和wc-l<file之间的差异，并找到一个明显的（2位数百分比）差异。每一个速度较慢的测试都将在绝对时间内付出类似的代价；然而，这将相当于其较大总时间的较小部分。

事实上，我在Linux 3.13（Ubuntu 14.04）系统上用一个1.5千兆字节的垃圾文件进行了一些快速测试，获得了这些结果（这些结果实际上是“三选一”的结果；当然，在启动缓存之后）：

$ 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的效率水平上，猫产生了巨大的差异：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）将输入文件映射到其地址空间，而不是使用显式读取（2）系统调用。这些差异对基准测试结果的影响可能远远大于运行cat二进制文件的小成本。

当然，如果同一个程序在两种情况下表现明显不同，这是一个有趣的基准测试结果。它表明，实际上，程序或其I/O库正在做一些有趣的事情，比如使用mmap（）。因此，在实践中，双向运行基准可能会很好；也许，为了“原谅”猫本身的运行成本，可以将猫的结果减去一些小因素。

顺便说一句，C++版本的行计数比Python版本的行数大一倍的原因是，只有当尝试读取超过eof时，才会设置eof标志。因此，正确的循环应该是：

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

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

出于好奇，我观察了引擎盖下的情况，并在每次测试中使用了dtruss/strace。

C++

./a.out < in
Saw 6512403 lines in 8 seconds.  Crunch speed: 814050

系统调用sudo dtruss-c/a.输出<输入

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<英寸

CALL                                        COUNT
__mac_syscall                                   1
<snip>
open                                            5
pread                                           8
mprotect                                       17
mmap                                           21
stat64                                         29

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

默认情况下，cin与stdio同步，从而避免任何输入缓冲。如果您将其添加到主菜单的顶部，您将看到更好的性能：

std::ios_base::sync_with_stdio(false);

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

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

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

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

幸运的是，库设计人员决定，如果您知道自己在做什么，也可以禁用此功能以提高性能，因此他们提供了sync_with_stdio方法。从该链接（添加强调）：

如果同步被关闭，则允许C++标准流独立地缓冲其I/O，在某些情况下这可能会快得多。