冗长地运行命令是否会使它们变慢？

Question

我发现自己-v越来越少地在许多应用程序中使用该标志（尤其是对于像tar和 之类的琐碎事物cp）。但是，当我解压缩一个大文件时，它会比我不使用-v标志时花费更长的时间。

我认为这是因为终端必须处理文本，而我正在填充它可能拥有的任何缓冲区。但我的问题是，这是否会使应用程序实际运行速度变慢，或者它是否在相同的时间内完成，而我所看到的是终端试图赶上？

Answer 1

是的，运行 verbose 会减慢您的应用程序的速度。

多少取决于应用程序。

每次打印到终端都需要额外的处理时间。在使用 printf() 或其任何姐妹的情况下，这会浪费大量的处理。

此外，终端必须处理该数据。应用程序和终端之间的缓冲区空间是有限的，IO 通道会阻塞，直到该缓冲区中有足够的空间来实际输出数据。在发生这种阻塞时，应用程序通常无法继续。¹

此外，在终端上显示调试文本的行为将消耗处理周期。同样，这取决于应用程序（调试数量）、终端程序（使用的字体、效果等）甚至使用的 X windows 驱动程序（硬件加速等）。

该time程序可用于相当准确地确定命令运行所需的时间。随着时间的推移运行相同的程序两次，一次有调试，一次没有，会告诉你它有多大的不同。我建议在执行测试之前运行该命令一次，以确保该命令的两次测试运行的缓存相同。您不想通过让第二次运行更快来歪曲结果，因为大多数数据都在第一次运行时缓存了，现在您...

¹在多线程应用程序的情况下，只有执行调试输出的线程才会实际阻塞。

Answer 2

这取决于您正在运行的应用程序。然而，一般来说，我们可以说verbose 会减慢大多数常见的Linux 应用程序的速度，因为它们必须在stdout 和I/O 或处理器边界之间同步它们的操作。

Answer 3

使用yes作为OS X 10.7的测试情况下，似乎如果打印大量输出到终端，正如人们所预料它确实很重要。

进一步量化这一点，我跑yes了 5 秒钟，在一种情况下将输出打印到终端并将其保存到文件（使用tee），在另一种情况下除了重定向stdout到/dev/null：

1. yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_term
2. yes | tee yeslog_noterm > /dev/null & sleep 5 && killall yes && wc -l yeslog_noterm

案例 1. 给出2371584行，案例 2. 给出136421376行，或者是 57 倍。yes在这种情况下（以每单位时间打印的行数来衡量）的“性能”因此慢了 57 倍。

这里要注意的一点是，我yes与teehere一起使用，这可能会稍微影响结果，但我认为结果仍然有效。

程序变慢的另一个迹象是，yes在输出到终端时运行，终端使用大约 100% 的 CPU，yes只有大约 37%，而在yes没有输出到终端的情况下运行时，它使用了完整的 100%（这是在一个多核心机器，所以yes如果可以的话，可以使用更多的 CPU，除非它被终端减慢了速度）。

Answer 4

回答“是”很容易，这会减慢应用程序的速度。但更真实的答案是在 99% 的情况下都无关紧要。

如果您的应用程序正在执行任何类型的工作，实际上需要一些 CPU 能力，那么在屏幕上打印一些额外的文本行并产生任何类型的差异的可能性接近 0%。

事实上，您可以很容易地做出自己的判断：如果应用程序喷出一堵巨大的文本墙，它实际上可能会花费您一点钱。也许。