はい、verbose を実行するとアプリケーションの速度が低下します。
アプリケーションによって異なります。
端末に出力するたびに、追加の処理時間が必要になります。 printf() またはその姉妹のいずれかを使用する場合、これはかなりの量の処理が無駄になります。
また、端末はそのデータを処理する必要があります。アプリケーションと端末の間には限られた量のバッファースペースがあり、実際にデータを出力するのに十分なスペースがバッファーに確保されるまで、IO チャネルはブロックされます。通常、このブロッキングが行われている間、アプリケーションは続行できません。
また、デバッグ用のテキストを端末に表示するという行為は、処理サイクルを消費します。繰り返しますが、これはアプリケーション (デバッグの量)、端末プログラム (使用されるフォント、効果など)、さらには使用中の X ウィンドウ ドライバー (ハードウェア アクセラレーションなど) の両方に依存します。
time プログラムを使用して、コマンドの実行にかかった時間をかなり正確に判断できます。同じプログラムを 2 回実行すると (1 回はデバッグあり、もう 1 回はなし)、どれだけの違いが生じるかがわかります。コマンドの両方のテスト実行でキャッシュが同じであることを確認するために、テストを実行する前にコマンドを 1 回実行することをお勧めします。最初の実行でほとんどのデータがキャッシュされたので、2 回目の実行を大幅に高速化して結果を歪めたくはありません...
マルチスレッド アプリケーションの場合、デバッグ出力を実行するスレッドのみが実際にブロックされます。
実行しているアプリケーションによって異なります。ただし、一般的に、verbose は最も一般的な Linux アプリケーションの速度を低下させると言えます。これは、標準出力と I/O またはプロセッサ境界の間でアクションを同期する必要があるためです。
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 を使用します。 yes の実行中は約 37% のみ 端末に出力せずに 100% を完全に使用します (これはマルチコア マシン上にあるため、yes 可能であれば、より多くの CPU を使用できますが、端末によって速度が低下することはありません)。