☰

ターミナルレンダリングとアプリケーションパフォーマンス

tag-icon • tag-icon terminal python
ターミナルレンダリングとアプリケーションパフォーマンス

私は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

端子出力が実際の性能に与える影響？

たとえば...シェルスクリプトの中で...！

#!/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

2 番目の例では、スクリプトがすばやく実行され、すべての出力データが /tmp/result.txt にすでに準備されています。

ウィンドウを最小化するだけでパフォーマンスの向上はほぼゼロになります。これは、アプリケーションがウィンドウを復元したときに表示されるように最小化された端末にログを記録し続けているためです。

パフォーマンスに影響を与えずにログファイルを生成せずにcomamndが返す内容を読むには、別のアプローチを試してください。

yourcommand | less

答え2

端末エミュレータを最小化しても、かなりの（または目立つ）改善効果を得る可能性はほとんどありません。

できるだけ早く入力を読み取って処理するグラフィカル端末エミュレータのコンポーネントです。たとえば、私のコンピュータでは、私が好むターミナルエミュレータは約10 MB / sの速度で読み取り、解析、および処理できます（もちろん、データ型によって異なります）。

端末エミュレータは、特定の入力を処理した直後に画面を更新しないため、耐えられないほど遅くなる可能性があります。 （Linuxコンソールが行うことです。フレームバッファを使用すると本当に耐えられないほど遅いですが、他のVTに切り替えると本当に速くなります）更新します。 。すべて適応フレームレートを実装する必要があります。つまり、塗装に時間がかかりすぎないようにする必要があります。何らかの理由で描画が遅い場合（たとえば、巨大な端末ウィンドウ、高速化されていないグラフィックカード）、多くのCPUがまだストリームを読み取るために使用できるように描画の頻度を減らします。

一般的な状況では、画面を毎秒数十回再描画するコストは、できるだけ多くのデータを読み取って解析するコストと、そのデータをエクスポートするアプリケーションのコストと比較してかなり小さくなければなりません。

アプリケーションのパフォーマンスが低下すると、端末エミュレータによるものではない可能性が高くなります。表現コンテンツが遅い。それはおそらくttyラインがカーネルとターミナルエミュレータを通過するからです。処理データが最小化されても、データをゆっくり処理する必要があります。

関連情報