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

37

我发现自己在-v越来越多的应用程序中使用该标志（特别是对于诸如tarand的琐碎事情cp）。但是，当我这样做的时候（例如，我要解压缩一个大文件），比不使用该-v标志的时间要长。

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

linux unix shell

— n0pe
source

你有没有尝试时如tar xvf file.tar > /dev/null对tar xf file.tar？重定向到/dev/null应该使您的终端摆脱困境。

— 本杰明·班尼尔

3

另外，请注意，stdout和stderr是行缓冲的 -意味着填充缓冲区不会花费那么长的时间-阻塞printf调用（以及扩展终端输出）将永远占用时间。

— 2011年

1

如果您谈论过Windows命令，我肯定会说这是真的:)

— kokbira 2011年

对于CPU密集型任务，根据您正在执行的IO数量，您可能会看到可怕的性能下降。

— 用户

31

是的，运行冗长会降低您的应用程序的速度。

多少取决于应用程序。

终端上的每份打印都需要额外的处理时间。在使用printf（）或其任何姐妹的情况下，这会浪费大量的处理资源。

而且，终端必须处理该数据。应用程序和终端之间的缓冲区空间有限，并且IO通道将阻塞，直到该缓冲区中有足够的空间可以实际输出数据为止。发生这种阻塞时，应用程序通常将无法继续。^1个

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

该time程序可用于相当准确地确定命令运行了多长时间。一次运行两次相同的程序，一次进行调试，一次不进行调试，将告诉您它产生了多少不同。我建议在执行测试之前运行一次命令，以确保两次命令测试的缓存都相同。您不想让第二次运行的速度更快而使结果出现偏差，因为您现在大部分数据都已被第一次运行缓存了……

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

— 马延科
source

大多数程序员学习起来都很快（DOS中的Borland C）；）

— Dragos

当然，如果控制台窗口是隐藏的（甚至被部分覆盖），则其影响不会像控制台可见时那样大。打开命令提示符并执行dir c:\/s/a。当速度变化完全可见并被部分覆盖时，您会看到速度变化。你不能看到最小化时，它加快了，但它绝对速度更快，但你不得不重新启动，如果你想测试中，为了绕过这将导致其更快无论如何，因为它不会有缓存访问磁盘。

— Synetech

1

@Syn我们在这里谈论Linux。

— 马琴科2011年

1

@Matt仍然是有效的评论。请尊重。

— nhinkle

@Matt，do！我没注意到（也许我从DOS注释中分心了。）无论如何，Linux是完全不同的，但是我想知道这是否也适用（具有大量文本滚动功能的可视控制台运行速度较慢）。

— Synetech

8

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

— 迪奥戈
source

6

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

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

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

情况1给2371584行，情况2给136421376行，或多于57倍。因此，“性能” yes（通过每单位时间打印的行数来衡量）要慢57倍。

这里的一个旁注是我yes与tee此处结合使用，这可能会稍微影响结果，但是我确实认为结果仍然有效。

程序变慢的另一个迹象是，yes在输出到终端时运行，该终端使用大约100％的CPU，yes仅使用大约37％，而在yes不输出到终端的情况下运行，则使用全部100％（这在多核心计算机，因此yes，如果可能的话，可以使用更多的CPU，但终端会降低它的速度）。

— 提姆
source

5

回答是很容易，这会降低应用程序的速度。但是，更真实的答案是，在99％的情况下都没有关系。

如果您的应用程序正在执行实际上需要占用CPU资源的任何工作，则在屏幕上打印一些额外的文本行以产生任何类型的差异的机会接近0％。

实际上，您可以轻松地做出自己的判断：如果应用程序喷出了巨大的文字墙，则实际上可能会花费您一点点钱。也许。

— slarpspark
source

3

-1这是不正确的。printf()太贵了

— Thomas Bonini 2011年

1

我说的是真的。但是，您试图使它看起来像我说的完全是另一回事。我没有说任何特定的stdlib打印效率的问题。我是说程序应该做的工作足以使打印时间可以忽略不计。现在去拖钓别人。

— slarpspark

@slarpspark：不必忽略不计，即使我们从等式中删除printf（），字节流仍必须经过bash，然后是终端仿真器，然后终端仿真器必须将文本呈现到屏幕中在解析了转义字符之后，如果以某些冗长的命令可能执行的速度完成文本渲染，那么它的价格将不菲。如果程序在每一行刷新输出缓冲区，那将特别昂贵，因为这意味着上下文切换。我在编写python脚本时经常会遇到这样的情况，即以紧密的循环删除打印有时会使10s变为1s。

— Lie Ryan

那么，通过SSH运行的命令又如何呢？即使CPU时间最短，但是一旦确定引入了网络延迟，那该怎么办呢？

— ec2011 18-10-25

3

冗长的代码通常使用if指令进行评估，并且每次将控制权传递给显示函数时，花费的时间越长，上下文可以被切换，中断就越多。

但这取决于您是否冗长的代码是一个单独的线程，该线程只是不时检查完成状态而导致的差异是可以忽略的。

这个问题可以从stackoverflow经验丰富的程序员的贡献中受益匪浅。我建议搬家:)

— 德拉戈斯
source