我发现自己-v越来越少在很多应用程序中使用该标志（尤其是对于像tar和 这样的琐碎内容cp）。但是，当我使用该标志时，例如，解压一个大文件时，它所花的时间会比不使用该标志时更长-v。
我认为这是因为终端必须处理文本，而我正在填充它可能有的任何缓冲区。但我的问题是，这是否实际上使应用程序运行得更慢，还是它在相同的时间内完成，而我看到的是终端试图赶上？
答案1
是的，运行详细模式会降低你的应用程序速度。
具体多少取决于应用程序。
每次打印到终端都需要额外的处理时间。在使用 printf() 或任何同类函数的情况下，这会浪费大量的处理时间。
此外，终端必须处理这些数据。应用程序和终端之间的缓冲区空间有限，IO 通道将阻塞，直到所述缓冲区中有足够的空间来实际输出数据。在发生这种阻塞时，应用程序通常无法继续运行。1
此外，在终端上显示调试文本的操作将消耗处理周期。同样，这取决于应用程序（调试量）、终端程序（使用的字体、效果等）甚至正在使用的 X windows 驱动程序（硬件加速等）。
该time程序可用于相当准确地确定命令运行所需的时间。两次运行同一个程序，一次调试，一次不调试，将显示它带来的差异。我建议在执行测试之前运行一次命令，以确保命令的两次测试运行的缓存相同。您不想让第二次运行速度更快，因为大多数数据在第一次运行时已被缓存，现在您...
1对于多线程应用程序，只有执行调试输出的线程才会真正阻塞。
答案2
这取决于您正在运行的应用程序。但是，一般来说，我们可以说详细会降低大多数常见 Linux 应用程序的速度，因为它们必须在 stdout 和 I/O 或处理器界限之间同步其操作。
答案3
很容易回答是的，它会减慢应用程序的速度。但更真实的答案是在 99% 的情况下这都不是问题。
如果你的应用程序正在执行任何需要 CPU 处理的工作，那么在屏幕上打印一些额外的文本行的可能性任何这种差异接近0%。
事实上，您可以轻松做出自己的判断：如果应用程序输出大量文本，实际上可能会花费您一点钱。或许。
答案4
详细代码通常用 if 指令进行评估，并且每次将控制权传递给显示函数时，花费的时间越长，上下文就会切换，中断也会越多。
但这取决于，如果你的详细代码是一个单独的线程，只是不时检查完成状态，那么差异是可以忽略不计的。
这个问题可以从 stackoverflow 经验丰富的程序员的贡献中受益匪浅。我建议你搬走 :)