2012年には、タブレットで作業する際の応答時間の効果を示す優れたMSRデモがあります。 3分間のビデオを見たくない場合、彼らは基本的に、1ミリ秒未満の任意の遅延をシミュレートするデバイスを作成しました。 現代のタブレットに典型的な100ミリ秒（0.1秒）の遅延は、ひどく見えます。 10ミリ秒（0.01秒）の間、遅延は顕著ですが、すでに正常に動作できます。1ミリ秒未満の遅延で、すべてが完璧です-紙に鉛筆で書いているかのように。 自分でテストする場合は、スタイラス付きのAndroidタブレットを使用して、Appleスタイラス付きの現行世代のiPad Proと比較してください。 Appleデバイスの応答時間は10ミリ秒をはるかに超えていますが、違いはとにかく基本的です-新しいiPad Proを実際に使用してメモを書き、図を描くのに対して、Androidタブレットは鉛筆と紙の代わりとして完全に受け入れられません。



遅延が異なるVRヘルメットでも似たようなものが表示されます。 20ミリ秒は正常に見え、50ミリ秒は遅れ、150ミリ秒はすでに耐えられません 。



奇妙なことですが、キーボードやマウスの入力の遅延に関する苦情はほとんどありません。 その理由は、キーボードとマウスの入力が非常に高速であるためと思われます-そして、それはほとんど瞬時に起こります。 そうだとよく言われますが、状況はまったく逆だと思います。 コンピューターがデータ入力に迅速に応答するという考え方-違いに気付かないほど速い-は、私がプロのプログラマーから聞いた最も一般的な誤解です。



テスターが通常のコンピューター構成でゲームの開始から終了までの実際の遅延を測定すると、通常、遅延が100ミリ秒の 範囲にあることがわかります。



Robert Menzelが作成したゲームパイプラインの遅延の分布を見ると、100 + msがどこから来ているのかを簡単に理解できます。

• 〜2 ms（マウス）
• 8 ms（ゲームによる入力処理の開始までの平均待機時間）
• 16.6（ゲームシミュレーション）
• 16.6（レンダリングコード）
• 16.6（GPUは前のフレームを描画し、現在のフレームはキャッシュされます）
• 16.6（GPUレンダリング）
• 8（vsyncの平均不一致時間）
• 16.6（ディスプレイフレームキャッシング）
• 16.6（フレームの再描画）
• 5（ピクセルスイッチング）

ここでは、ゲーミングマウスとかなりまともなLCDの使用を意図していることに注意してください。 しかし実際には、マウスの遅延とピクセルの切り替えがはるかに大きくなることがよくあります。



システムを構成して40ミリ秒の範囲に収めることができますが、ほとんどのユーザーはそうではありません。 そして、たとえそうだとしても、タブレットやVRヘルメットが「本来どおりに」動作を開始する10〜20ミリ秒の範囲からはほど遠いです。



ゲーマーは他のほとんどの人よりも重要であるため、キーを押してから画面を表示するまでの遅延の測定は通常ゲームで行われますが、他のほとんどのアプリケーションは応答時間においてゲームと大きく異なるとは思いません。 通常、ゲームは「典型的な」アプリケーションよりも各フレームでより多くの作業を行いますが、最適化されています。 メンゼルは、ゲームロジックの半分とレンダリングの半分を含む33ミリ秒の予算をゲームに与えます。 ゲーム以外のアプリケーションの応答時間はどのくらいですか？ Pavel Fatinはテキストエディターでそれを測定し、数ミリ秒から数百ミリ秒の遅延を発見しました-そして、彼は他のアプリケーションの評価にも使用できる測定用の特別なアプリケーションを書きました 。 java.awt.Robotを使用して、キーストロークと画面キャプチャを生成します。



個人的には、何らかの理由で、さまざまなコンソールとシェルの応答時間を調べたいと思います。 まず、コンソールで時間の大部分を費やし、通常はその中で編集するため、ここでの入力遅延はコンソールに一部起因します。 第二に、ほとんどの場合（約2桁多い）、テキスト出力速度は、大きなファイルでcat



を実行することで測定されることが多く、コンソールベンチマークとして提供されます。 これはかなり役に立たないベンチマークであるように思えます。 cat



を使用してファイルを処理し、コンソールにstdout



を発行する速度によって、タスクを最後に実行した時間が制限されたことを思い出せません（emacsでeshellを使用しない限り）。 そして、そのような特殊な次元が役立つ単一のタスクを想像することはできません。 私にとって重要な次のタスクは、誤って大量の出力をstdout



送信したときの^C



割り込みコマンドの実行速度です。 しかし、実際の測定からわかるように、コンソールが大量の入力をstdout



出力へのstdout



とともに吸収する能力は、 ^C



への応答時間とはほとんど関係がありません^C



ページ全体を上下にスクロールする速度は関連しているように見えますが、実際の測定では、これらの2つのパラメーターはあまり相関していません（たとえば、emacs-eshellはすばやくスクロールしますが、 stdout



非常にゆっくり吸収します）。 他に気になるのは応答時間ですが、特定のコンソールがstdout



迅速に処理しているという情報は、応答時間についてあまり語っていません。



いくつかのコンソールの応答時間を見てみましょう-それらのどれも顕著な遅延を追加します。 キーを押してからラップトップの内部スクリーンキャプチャまでの応答時間を測定する場合、異なるコンソールの遅延は次のとおりです。







これらのグラフは、さまざまなコンソールの遅延の分布を示しています。 縦軸はミリ秒単位の遅延です。 水平軸に沿ったパーセンタイル（たとえば、50はデータの50％が50パーセンタイルを下回ることを意味します。つまり、これは平均クリック数です）。 特に指定がない限り、macOSで行われた測定。 左側のグラフは無負荷の車に対応し、右側のグラフは負荷のかかった車に対応しています。 平均値の中央値のみを見ると、一部の端末は非常によく見えます。terminal.appとemacs-eshellは、アンロードされたシステムで約5ミリ秒です。 これは、ほとんどの人が遅延に気付かないほど小さいです。 しかし、ほとんどのコンソール（st、alacritty、hyper、iterm2）は、 ユーザー がロードされていないシステムであっても、 追加の遅延にすでに気づいている範囲にあります 。 グラフの末尾、たとえば99.9パーセンタイルの応答を見ると、すべてのコンソールは、ユーザーの認識の調査に従って、追加の遅延が顕著になるはずの範囲に入ります。 比較のために、内部で生成されたキーストロークと一部のコンソールのGPUメモリに入るまでの遅延は、 ボストンからシアトルまでのパケットの移動時間 （約70ミリ秒）を超えています 。



すべての測定は、各コンソールを個別にテストするときに、A / Cケーブルからの電力なしでバッテリーをフル充電して実行されました。 負荷時の測定は、Rustのコンパイル中に行われました（以前と同様に、A / Cケーブルからの電力なしでバッテリーをフル充電し、結果の再現性のために、すべての依存関係をダウンロードした後、Rustのクリーンビルドから15秒後に各測定を開始しましたが、テストとテストの間に十分な時間を設けて、テスト間の体温調節による干渉）。



負荷時の平均遅延の中央値を見ると、emacs-termに加えて、他のコンソールの結果は、アンロードされたマシンよりもそれほど悪くありません。 ただし、90パーセンタイルや99.9パーセンタイルのように、グラフの末尾では、各コンソールの応答性が大幅に低下します。 macOSからLinuxに切り替えても画像はあまり変わりませんが、コンソールが異なれば異なります。



これらの結果は、最悪の場合のシナリオよりもはるかに優れています（低バッテリー充電で、コンパイルが開始されてから10分待って温度調整によるノイズが悪化すると、数百ミリ秒の遅延が発生する可能性があります）、それでも各コンソールにはグラフの末尾に遅延があります人に目立つようにしてください。 また、これは、入出力処理パイプラインの開始から終了までの合計応答時間のほんの一部に過ぎないことを忘れないでください。



キーボード入力と画面出力の間の遅延について、スタイラスで描画したときやVRヘルメットで描画したときと同じように不平を言わないのはなぜですか？ 私の理論では、VRとタブレットの場合、人々は同様の「アプリケーション」で多くの経験を持ち、レイテンシーがはるかに少ないと考えています。 タブレットの場合、このような「アプリケーション」は鉛筆と紙であり、仮想現実の場合-VRヘルメットなしでのみ頭を向ける普通の世界です。 しかし、キーボード入力と画面への出力の間の応答時間はすべてのアプリケーションで非常に長いため、ほとんどの人は当然大きな遅れを取るだけです。



別の理論は、キーボードとマウスの入力がタブレットの入力と根本的に異なるため、遅延が目立たなくなるというものです。 データがなくても、このような理論は信じられないようです。なぜなら、数十ミリ秒余分にリモート端末を介して接続すると、キーを押したときに顕著な遅れを感じるからです。 そして、A / Bテストに余分な遅延を追加すると、前に説明した範囲の遅延に気付くことができます。



そのため、最も一般的なベンチマーク（標準出力のパフォーマンス）と異なるコンソールの遅延を比較する場合、異なるコンソールが標準出力への出力のために入力データを処理する速度を測定してみましょう。

コンソール	標準 （MB / s）	idle50 （ミリ秒）	load50 （ミリ秒）	idle99.9 （ミリ秒）	load99.9 （ミリ秒）	mem （MB）	^ C
怠lac	39	31	28	36	56	18	わかった
terminal.app	20	6	13	25	30	45	わかった
st	14	25	27	63	111	2	わかった
怠lacなtmux	14
terminal.app tmux	13
iterm2	11	44	45	60	81	24	わかった
ハイパー	11	32	31	49	53	178	失敗する
emacs-eshell	0.05	5	13	17	32	30	失敗する
emacs-term	0.03	13	30	28	49	30	わかった

stdout



パフォーマンスとコンソールの表示速度の関係は明らかではありません。 このテストでは、terminal.appは外部からは非常に悪く見えました。 スクロールすると、画面がめったに更新されないように、テキストがぎくしゃく移動しました。 問題はハイパーおよびemacs-termでも観察されました。 Emacs-termは出力にまったく対応していませんでした-テストが完了してから、最後まで更新するのに数秒かかりました（表示された行数を示すステータスバーは関連性があるように見えたため、テストが終了するまで数は増加しませんでした）。 ハイパーラグがさらに遅れ、数回点滅しても、画面はほとんど更新されませんでした。 Hyper Helper



プロセスは、約2分間CPU使用率100％で人為的にサポートされ、コンソールは常に完全に応答しませんでした。



このコンソールはスクロールアップをサポートしていないため、Alacrittyはtmuxマネージャーでテストされており、ドキュメントにはtmuxを使用する必要があると記載されています。 比較のために、terminal.appもtmuxでテストしました。 ほとんどのコンソールでは、tmuxはstdout



の速度を低下させないようですが、alacrittyとterminal.appは十分に高速であるため、実際にはtmuxの速度によってパフォーマンスが制限されていました。



Emacs-eshellは技術的にはコンソールではありませんが、場合によってはこのプログラムをコンソールの代替として使用できるため、eshellもテストしました。 実際、eshellとtermの両方のEmacsは非常に遅いことが判明したため、 stdout



生成する実際の速度には関係ありません。 過去に、eshellまたはtermを使用しているときに、 stdout



またはstderr



で詳細ロギングを使用してコマンドを実行すると、数千行のテキストのスクロールを待つことがありました。 これは非常にまれにしか発生しないため、私にとっては、遅延が0.5または1秒に達するまでこれは大きな問題ではありませんが、他のコンソールではすべて正常に動作します。



逆に、ロングテールの遅延に気付くのに十分な速さで文字を入力しています。 たとえば、1分あたり120ワード、つまり1秒あたり10文字と入力すると、99.9パーセンタイル（1000分の1）のテールが100秒ごとに表示されます！



いずれにせよ、「ベンチマーク」の代わりに、 cat



は、数千行ではなく数百万行の出力を含むコマンドを誤って実行した場合に^C



プロセスを中断できるかどうかに関心があります。 hyperおよびemacs-eshellを除き、ほぼすべてのコンソールがこのテストに合格します-両方とも少なくとも10分間フリーズします（10分後にタスクを強制終了し、プロセスが終了するのを待ちません）。



この表には、プログラムのロード時のメモリ使用量も含まれています。コンソールをテストするときにこのパラメーターを使用することが多いためです。 起動時のコンソールがメモリで40 MBを占有することは少し奇妙に思えますが、3歳のラップトップでも16 GBのRAMがインストールされているので、これらの40 MBから2 MBを最適化してもプログラムに実際には影響しません。 くそー、最近買った300ドルの「Chromebook」にも、16 GBのRAMがインストールされていました。

おわりに

ほとんどのコンソールの応答時間は十分に長いため、開発者が新しい機能やパフォーマンスの他の側面を追加するのではなく、このパラメーターに焦点を合わせた場合、プログラムを操作するときのユーザーエクスペリエンスを改善するように最適化できます。 しかし、コンソールベンチマークを探したときに、プログラムの作成者が何かのパフォーマンスを測定した場合、 それは stdoutの出力速度か、ブート時のメモリ使用量である ことがわかりました。 これは悲しいことです。ほとんどの「遅い」コンソールは、人々が理解できるよりも数桁早くstdout



既に発行しているため、 stdout



速度のさらなる最適化は、ほとんどのユーザーの実際のユーザビリティに比較的弱く影響します。 コンソールが古いラップトップまたは最新の安価なモデルのメモリの0.01％を使用する場合、ブート時のメモリ使用量を削減することについても同じことが言えます。



コンソールで作業している場合、応答時間と対話性の比較的優れた最適化（たとえば、 ^C



への反応）と、ブート時のスループットとメモリ使用量の比較的少ない最適化を行うことがより重要な場合があります。



更新。 この記事への回答として、 alacrittyは、遅延の遅延がどこから来て、どのように減らすことができるかを説明しました 。

付録：否定的な結果

Tmuxと遅延。 さまざまなコンソールでtmuxマネージャーをテストしましたが、違いは測定誤差の範囲内であることがわかりました。



シェルと遅延。 さまざまなシェルをテストしましたが、最速のコンソールでも、それらの違いは測定誤差の範囲内でした。 私の実験的なセットアップでは、Powershellが色を正しく処理しないため、Powershellをチェックするのが少し困難でした（入力された最初の文字はコンソールの色セットで入力されますが、設定に関係なく残りの文字は黄色で、このバグは閉じようとしているようです ）。使用されます。 また、Powershellはカーソルを常に正しい場所に配置するわけではありません -線に沿ってランダムにジャンプするため、画像認識設定が乱れます。 しかし、これらの問題にもかかわらず、Powershellは他のシェルと同等のパフォーマンスを備えています。



シェルおよび標準出力の帯域幅。 前のケースと同様に、異なるシェルの違いは測定誤差の範囲内です。



単一行および複数行のテキストと帯域幅。 一部のテキストエディターは非常に長い行で動作しますが、スループットは実質的に変わりません。そのような行を1つ含むファイルをコンソールにプッシュするか、80文字の行に分割しました。



キューロック/データスキップエラー。 これらのテストは、10.3文字/秒の入力速度で実行しました。 しかし、入力速度が遅延に大きな影響を与えないことが判明しました。 理論的には、コンソールがいっぱいになる可能性があり、非常に高い入力速度で最初にクラッシュしたのはハイパーでしたが、これらの速度は私が知っている人のテキスト入力の速度よりもはるかに高速です。

アプリケーション：実験的インストール

すべてのテストは、2014年半ばのデュアルコアMacbook Pro 13インチ2.6 GHzで実施されました。 このマシンには16 GBのRAMと2560×1600文字の画面解像度があります。 OS Xバージョン10.12.5。 Linux（Lubuntu 16.04）でいくつかのテストを実施して、macOSとLinuxを比較しました。 各遅延測定は、10,000回のキーストロークに制限されていました。



測定はボタンを押すことで実行されました.



デフォルトではbase32



エンコーディングの出力、つまり、プレーンASCIIテキストを使用します。 ジョージキングは、さまざまな種類のテキストが配信速度に影響を与える可能性があるという事実に注目しました。

Terminal.appが非ラテンエンコーディングを発行すると大幅に遅くなることに気付きました。 これには3つの理由があると思う：異なるフォントページをロードする必要性、Basic Multilingual Plane（BMP）外のコードポイントを解析する必要性、Unicodeマルチバイト文字。



おそらく最初の方法は、フォントグリフの遅延読み込み、フォールバックフォントの計算、グリフページのキャッシュなどの非常に複雑な組み合わせになります。



2番目は少し推測ですが、Terminal.appはUTF16に基づくCocoa NSStringを使用することをお勧めします。これは、サロゲートペアのためにコードポイントがBMPよりも高い場合、ほぼ確実に速度低下につながります。

テストを実行する前に、コンソールを全画面に展開しました。 これは結果に影響し、コンソールウィンドウのサイズを変更するとパフォーマンスが大幅に変わる可能性があります（たとえば、他の要素を変更せずにウィンドウのサイズを変更することにより、iterm2よりも非常に遅くすることができます）。 macOSのstは、XQuartzの下でクライアントXとして開始されました。 XQuartzが本質的に遅いバージョンをテストするために、XQuartzを使用するもう1つの「ネイティブ」Linuxコンソールrunesを試しました。 ルーン文字のテール遅延は、stおよびiterm2よりもはるかに小さいことが判明しました。



「アンロードされた」システムの遅延テストは、システムの再起動直後に実行されました。 すべてのターミナルは開いていましたが、テキストはそのうちの1つだけに入力されました。



ロード中のテストは、Rustのバックグラウンドコンパイル中、コンパイル開始から15秒後に実行されました。



コンソールスループットテストは、擬似ランダムテキストを含む大きなファイルを作成することにより実行されました。



timeout 64 sh -c 'cat /dev/urandom | base32 > junk.txt'







その後の起動で



timeout 8 sh -c 'cat junk.txt | tee junk.term_name'







ターミネーターとurxvtはmacOSにインストールするのは簡単な手順ではないため、テストされていません。それらを機能させようとするのは面倒です。 ターミネーターはソースから簡単にコンパイルできますが、起動時にフリーズし、コマンドラインは表示されません。 Urxvtはbrew経由でインストールされますが、依存関係の1つ（これもbrew経由でインストールされます）が間違ったバージョンであったため、コンソールがロードできませんでした。