☰

终端渲染和应用程序性能

tag-icon • tag-icon terminal python
终端渲染和应用程序性能

我正在用 cinnamon 运行 Mint 19，但我认为这对于任何 Linux 桌面环境来说都是一个普遍问题。我有一个 python CLI 应用程序，它有很多终端输出，以至于终端窗口中呈现的打印语句实际上减慢了应用程序的速度。一个蹩脚的问题：如果终端最小化（渲染是不必要的，也许可以省略），速度是否会提高？

答案1

如果您想要提高性能，请考虑使用以下命令运行命令：

mycommand &>/dev/null

或者

mycommand &>~/mycommand.log

另一种方式也很好：

nohup mycommand

注意：这&是不是将应用程序置于后台但重定向标准输出和标准错误。

一些基准：

time hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3
real    0m17,525s

time hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3  &>/dev/null
real    0m0,226s

time hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3  &>/tmp/result.txt
real    0m0,244s

time nohup hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3  
real    0m0,251s

终端输出如何影响现实世界中的性能？

例如...在 Shell 脚本内...！

#!/bin/bash
date >/tmp/start.txt
hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3 
date >/tmp/theend.txt

结果 ：

cat /tmp/start.txt 
qua jan  9 14:49:08 -02 2019
cat /tmp/theend.txt
qua jan  9 14:49:25 -02 2019

正如您在第一个示例中看到的，解释器在执行下一个命令之前等待所有输出 - 这在很多情况下可能很糟糕。

现在又来了没有直接向终端写入数据...

#!/bin/bash
date >/tmp/start.txt
hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3 >/tmp/results.txt 
date >/tmp/theend.txt

结果 ：

cat /tmp/start.txt
qua jan  9 14:52:02 -02 2019
cat /tmp/theend.txt
qua jan  9 14:52:02 -02 2019

在第二个示例中，脚本运行得很快，所有输出数据都已在 /tmp/result.txt 中为您准备好。

如果您只是最小化窗口，则性能增益几乎为零，因为应用程序仍在将日志写入最小化的终端，因此当您恢复窗口时您可以看到。

如果您想读取 comamnd 返回的内容，而又不影响其性能且不创建日志文件，请尝试其他方法：

yourcommand | less

答案2

通过最小化终端模拟器，您不太可能获得显着（甚至明显）的改进。

图形终端仿真器的一个组件负责尽快读取和处理输入。例如，我计算机上的首选终端模拟器可以读取、解析和处理大约 10 MB/s（当然，这取决于数据类型）。

终端模拟器不会在处理某些输入后立即更新屏幕，这会慢得难以忍受。 （这就是 Linux 控制台所做的事情，使用帧缓冲区确实慢得难以忍受，但一旦切换到另一个 VT，速度就会变得非常快。）相反，图形终端模拟器每秒更新显示几次（可能是 20-60 次） 。他们都应该实现自适应帧速率，即确保他们不会花费太多时间进行绘画。如果由于某种原因（例如巨大的终端窗口、非加速显卡）绘制速度很慢，它们会降低绘制频率，以确保仍然可以投入大量 CPU 来读取流。

在正常情况下，每秒重新绘制屏幕几十次的成本相对于读取和解析尽可能多的数据的成本以及应用程序发出这些数据的成本来说应该相当小。

如果您的应用程序的性能确实变慢，则可能不是因为终端模拟器渲染内容缓慢，可能是因为 tty 线路穿过内核以及终端仿真器加工即使数据最小化，他们也必须缓慢地处理数据。

相关内容