この記事では、タイピング遅延（キーボード入力または「入力ラグ」）の人間と機械の側面を研究し、一般的なテキストおよびコードエディターで作業する際の遅延に関する実験データを示します。



最近、 遅延はコンピューターの世界でホットな話題になりました。現在、低遅延のキーボード、144 Hzのモニター、遅延時間を短縮する特別な技術（ FreeSyncやG-Syncなど ）、これに関心のあるコミュニティなどがあります。 もちろん、このファッションの一部はマーケティングによって作成されましたが、実際には、わずかな遅延が可能になり、望ましいものになりました。



明らかに、ゲーマーはそのような改善の恩恵を受ける最初の人です。 バーチャルリアリティなどの一部の領域では、待ち時間は1ミリ秒になる場合でも決定的な要因です。 しかし、プログラマはどうでしょうか？ 「喜びを持って発展する」ためには、「喜びを持って印刷する」必要がありますか？ それを理解しましょう。



内容：



1. 男の側

1.1。 フィードバック

1.2。 運動能力

1.3。 内部モデル

1.4。 マルチタッチ統合

1.5。 効果

2. 機械の側面

2.1。 入力遅延

2.2。 処理遅延

2.3。 出力遅延

2.4。 完全な遅延

3. エディターの比較テスト

3.1。 構成

3.2。 方法論

3.3。 窓

3.4。 Linux

3.5。 Virtualbox

4. 結論

5. 参照

1.男の側

キーボード入力遅延とは、キーストロークと対応する画面の更新の間の時間間隔を指します。 簡単に聞こえますが、間違えないでください：キーボード入力プロセスへの影響は非常に複雑です。なぜなら、そのようなタイピングは、私たちの体と神経系の協調した行動の驚くべき現れであるからです（少なくとも技術的な観点から）。



基本から始めましょう-一般的に、遅延を心配することは価値がありますか？ 急ぐ必要はありません。必要なものを印刷して、後で結果を確認できます。 数秒で何も解決しませんよね？ そうでもない。

1.1。 フィードバック

人は自分が望むものを「ただ印刷」するのではありません。 私たちの感情はいわゆる 動きを伴う閉ループ制御 。 視覚画像は入力の結果だけではありません。 これはプロセスの不可欠な部分です 。



キーボードの操作（入力）の際に、より完全なフィードバックがあればあるほど良いです。 原則として、目を閉じて印刷できます。 耳を塞いでも、指の触覚だけに頼って入力を続けることができます。 ただし、この最後のフィードバックチャネルをブロックすると、キーボード入力が不可能になります。 感覚の視覚形態が支配的であり （他の感覚からの情報は通常視覚に適応する）、入力エラーに関する信頼できるデータを取得する唯一の方法であるため、視覚フィードバックは非常に重要です。



遅延を減らすと、フィードバックループが「短縮」され、入力が簡単になり、速度と精度が向上します。 これまでのところ悪くはありませんが、合理的な境界線はどこにありますか？ 最終的に、 人は信じられないほどゆっくりと反応します-感情から意識へ、そして筋肉への「行き来」には約200ミリ秒かかります！ 確かに、反応は訓練することができ、人々にとっては異なりますが、100ミリ秒などの比較的小さな遅延が良い選択肢のようです。 まったくありません。

1.2。 運動能力

最初にコンピューターのキーボードを使用しようとしたことを思い出してください。 ほとんどの場合、適切なキーを押してから画面上の結果を確認するのに数分かかりました。 このプロセスにはすべての焦点が必要でした。 しかし、数か月と数年が経ち、キーボードで驚くほど速く半自動で入力しているようになりました。特定のキーについて考える必要がなくなり、キーボードをまったく見ていません（ 「タッチタイピング」 ）。 練習が影響します。 このプロセスは「運動能力の獲得」 （または運動能力の獲得 （ 運動学習 ））と呼ばれます。 スキルが自律フェーズに到達すると、タスクはその実装に注意を引くことなく「自動的に」実行できます。



正式には、タイピング（キーボード入力）は、人の運動系の動きを制御するプロセスです 。 タイピング（キーボードでのタイピング）は細かい運動 （小さな筋肉の協調運動が発生する）であるため、フィードバックに大きく依存しています 。 ただし、このフィードバックは潜在意識レベルで処理されるため、必ずしも深刻なマイナスの影響を経験しながら遅延を認識する必要はありません。 人間の応答時間は、エラー修正にのみ関係します。



しかし、半自動プロセスでさえ視覚的な遅延 （pdfファイル）によって制限されており、フィードバックは使用できる場合にのみ有効です。 人間の視覚システムは、入力の処理に約40ミリ秒かかります。 この値は、多くの要因、特定の人にも依存し、トレーニングによって改善できます。 結論：20ミリ秒未満の遅延は許容範囲内ですか？ そうでもない。

1.3。 内部モデル

まず、「外部の」遅延は視覚的な遅延に追加され、視覚的な遅延に重畳されないことを明確にします。 遅延の問題。 ただし、約20 msの値はまだ比較的小さいと言えます。 良いですが、人間の運動システムは、より速く反応するためのいくつかの巧妙なトリックを知っています。



感覚器官と神経系の入力遅延に対処するために、人間の運動制御システムは内部モデルとして知られる特別な神経プロセスを使用します。 このプロセスは、フィードバック信号を受信する前であっても、制御されたシステムの応答（反応）を模倣できます-プロセスの高度なモデリングの使用。 追加の逆モデルは 、電流フィードバックに基づいて制御システムの応答（反応）を予測するように設計されています。



遅延はフィードバックループに直接影響を与えるのではなく、印刷プロセスの内部モデルに影響を与えます。 直接モデルと逆モデルは 、いくつかの内部フィードバックループと組み合わせて使用され 、 非線形システムを形成します 。 その結果、フィードバック信号のわずかな遅延でも、キーボードでの入力時（入力中）に重大な違反につながる可能性があります。



内部モデルとは別に、視覚的な遅延によって悪影響を受ける別のプロセス- 多感覚統合があります。

1.4。 マルチタッチ統合

キーボードで入力するときの視覚的なイメージは、フィードバックの唯一のタイプではありません。キーを押すと音が聞こえ、指に圧力を感じ、手と指の位置を認識できます（いわゆる固有受容 ）。



これらの感覚はそれぞれ別々に処理され、神経系は特定の信号グループを使用するかどうかを決定します。 このタスクはバインディングの問題として知られており、それ自体が課題です（たとえば、 多感覚錯覚を参照）。 脳がほとんどの感覚からすぐに影響を受け、画像がさらに遅延して到着すると、状況がさらに複雑になります。



神経系は視覚フィードバックの一定の遅延にある程度（pdfファイル） 適応できます（理想的ではありませんが）が、遅延の長さの不規則性（いわゆるジッター）は固有の予測不能性により追加の問題を引き起こします。



初期活動が完全に不可能になる状況まで、フィードバック信号の遅延がその完全な不在よりも悪い結果を引き起こす可能性のある他の分野からのいくつかの実例があります：コンピューターを介してMIDIキーボードで演奏する場合、 音の遅延は 20-30ですあなたの行動を混乱させるにはmsで十分です（1つの記事 （pdfファイル）では、約1 msでも音の遅延が問題であると主張しています）。 別の良い例は、いわゆる SpeechJammer （pdfファイル）（「チャッターファイター」）。 200 ms、一時的に人の話す能力を妨害します。

1.5。 効果

キーポイントをまとめる：



•入力（キーボードでの入力）は複雑な半自動プロセスであり、習得するには何年もかかります。

•原則として、印刷プロセスは、視覚フィードバックのミリ秒の遅延の影響を受けます。

•あなたの意識が遅延の存在を認識する必要はありませんが、それでもなお、それはあなたに悪影響を及ぼします。

•人の感受性と遅延耐性は大きく異なります。



しかし、遅延はタイピングプロセス（キーボード入力）にどの程度影響しますか？ 考えられるいくつかの効果があります。



•印刷が遅くなります。

•エラーとその修正の数が増えています。

•目が疲れます（ビジョンシステムが過負荷になっているため）。

•筋肉がより疲れます（モーションコントロールの定義が少なくなるため）。

•プロセスには、より意識的な注意が必要です。



遅延の正確な影響は、遅延の特定の分布、使用されるハードウェア（キーボード、モニター）、エディターの内容（テキストまたはコード）、メインアクティビティ（挿入/編集）、印刷方法（通常/ブラインド印刷）、仕様など、多くの要因に依存しますあなたのビジョンと運動能力、個人的な好みなど



言うまでもなく、遅延の影響の可能性はほとんどありません。 良いニュースは、これが両方向で機能することです。つまり、視覚的な遅延を減らすことにより、一般的な場合、多くの側面を改善できます（これは印刷速度そのものではありません）



原則として、得られた結果は利用可能な研究データと一致しています。 このテーマをより深く理解したい場合は、遅延の影響に関するデータや印刷プロセスに対する視覚的フィードバックの役割に関するデータを含む書籍や科学記事をご覧ください。たとえば、



• プロのタイプライティングの認知的側面

• プロのタイプライティングにおける画面と手の視覚フィードバックの役割 （pdfファイル）



特に、以下を引用する価値があります（ source ）：

コンピューターのディスプレイ上の視覚的フィードバックの遅れは、オペレーターの行動と作業に対する彼の満足度に重要な影響を及ぼします。

では、マシンの側面を見て、遅延状況を改善する方法を見つけましょう。

2.機械の側面

キーが押されてからキャラクターが画面に表示されるまでの間に何が起こりますか？ いろいろなことがあり、すべてに時間がかかることがわかりました。 静かなタイピングを保証するために、単にトップエンドのコンピューターを購入することは可能ですか？ このプロセスの多くの部分は中央および/またはグラフィックプロセッサから独立しているため、これは役立ちますが、ある程度のみです。 両方の錠剤を服用すると、ウサギの穴がどのくらい深くなるかをお見せします（これは真実の一部にすぎないためです）。



印刷遅延は、次のコンポーネントに分割できます。



•入力遅延（キーボード）

•処理遅延（ソフトウェア）

•出力遅延（モニター）



各コンポーネントを詳しく見てみましょう。

2.1。 入力遅延

最初に、通常の非ゲーミングUSBキーボードが入力をどのように処理するかを理解しましょう。 このようなキーボードは、デスクトップコンピューターとラップトップの両方で現在最も広く使用されています。



キーボードスキャン



通常のキーボードには100を超えるキーが含まれていますが、これはかなりの量です。 制御プロセッサのワイヤと入力の数を最小限に抑えるために、キースイッチは通常、 マトリックス回路に接続されます。 ワイヤの「行」と「列」が交差します。 このため、ワイヤと入力の数を「x * y」から「x + y」に減らすことができます（たとえば、121から22）。 このアプローチの結果、コントロールプロセッサはすべてのキーの状態を同時に読み取ることができません。一定の頻度で定期的にスキャンする必要があり、遅延が発生します。 マトリックスの一般的なスキャン周波数は1,000 Hzであるため、スキャンに関連する最大遅延は1 ms（平均-0.5 ms）です。



連絡先のバウンス



キーボードのタイプに関係なく、キースイッチは機械的に不完全であり、 バウンスに接触する傾向があります。「クリーン」な応答の代わりに、スイッチは停止する前に数回オン状態からオフ状態に切り替わります。 バウンスの期間は、スイッチングテクノロジーによって異なります。 たとえば、 前述のCherry MXデバイスの場合、5ミリ秒未満です。 正確な確率分布は不明ですが、対応する経験的データに基づいていますが 、約1.5ミリ秒のバウンス期間を取ることができます。



連絡先のバウンス



ポーリングの頻度は非常に高いため、チャターはいくつかのキーストロークとして解釈される可能性があるため、キーボードコントロールプロセッサはいわゆる 信頼できる結果を得るのに十分な時間間隔で信号を平均化することにより、接触バウンスを排除します。 このようなフィルタリングは、マイクロコントローラーのファームウェアに応じて、追加の遅延をもたらします。 一般に、製造業者はマイクロプログラムの特性を報告しないため、チャタリングを除去するための典型的なアルゴリズムを検討し、フィルタリングにより約10 7ミリ秒の遅延。 かくして 最大の「チャター除去時間」は約 12ミリ秒、平均約 8.5ミリ秒



USBポーリング



USBはホストコンピューターによって制御されるバスであるため、キーボードはこのコンピューターからの要求を登録キープレスに関する情報を送信するのを待つ必要があります（キーボード制御プロセッサーは収集されたイベントを出力バッファーに配置します）。 USBデバイスは初期化中に必要なポーリング周波数（最大1,000 Hz）を要求しますが、オペレーティングシステムは通常、低速およびフルスピード（USB1.x）デバイスの両方に125 Hzを使用します。 したがって、ポーリングに関連する最大遅延は8ミリ秒（平均4ミリ秒）です。 多くの場合、ポーリングの頻度を手動で増やすことができることに注意してください。



USB変換



データ変換にも時間がかかります。 ロースピードデバイスとフルスピードデバイスの両方で、最短の変換時間は1ミリ秒です。 高速デバイス（USB2）の場合、この時間ははるかに短くなります。 0.001 ms（ところで、 リアルタイムシステムに対するUSB​​の適合性に関する優れた記事があります （pdfファイル））。 データ変換時間を最小限に抑えるため、USBブロードバンドデバイス（ストレージデバイス、サウンドカード、Webカメラなど）を、キーボードが接続されているのと同じUSBコントローラー/ハブに接続しないことをお勧めします。



それでは、典型的なキーボードの遅延値を収集しましょう。

出所	分、さん	マックス・ミズ	平均
マトリックススキャン	0	1	0.5
コンタクトバウンス	7	12	8.5
USBポーリング	0	8	4
USB変換	1	1	1
合計	8	22	4

これらの結果は、一般に、キーボードによる遅延の測定に関するいくつかの実験結果に対応しています。



もっと良くすることは可能ですか？ もちろん、梨を砲撃するのと同じくらい簡単です！ プロのキーボードを使用します。



•短いバウンス時間のスイッチ（一部は光学式 ）

•高周波スキャンマトリックス

•適応チャッター除去アルゴリズム

•カスタムファームウェア

•迅速なポーリングと低い変換遅延のためのUSB2



これにより、最大および平均キーボードレイテンシの両方を大幅に削減できます。 たとえば、 Kinesis Advantageキーボードを購入したとき、以前の「通常の」キーボードとすぐに違いを感じました。



ゲーム用キーボードはさらに進化します-妥協のないソリューションのサポーターであれば、 チェリーのRealKeyテクノロジーのようなものを検討する必要があります。この技術では、キーは（デジタルではなく） アナログ入力を介して読み取られます。 遅延はほぼゼロです。

2.2。 処理遅延

処理遅延は、キーボードから入力信号を受信して​​からビデオフレームに入力された文字の画像を生成するまでの遅延です。 簡単に言えば、これはコンピューター自体の内部の遅延です。



処理遅延はパフォーマンスだけで決まるのではないことに注意してください。理論的には、入力後5秒の「遅延」で300 FPSを発行するシステムを使用することが可能です。 特に、パケット化とバッファリングは、多くの場合、遅延のためにより高いパフォーマンスを達成するための試みです。



概念的には処理遅延のさまざまな原因がありますが、実際にはエディタの使用と密接に関連しているため、通常はすべての部分が一緒に測定されます（実験データについては次の章を参照）。



オペレーティングシステム



USB ホスト （コンピューターの「USBポート」）はキーボードからデータを受信すると、ハードウェア割り込みを開始し、オペレーティングシステムのソフトウェアドライバーが受信したデータをホストコントローラーインターフェイス （通常はPCIまたはPCIe経由）で読み取れるようにします 。 次に、このデータはOS のヒューマンマシンインターフェイス （HID） サブシステムによって処理され、最終的にオペレーティングシステムのメッセージキューに 「キーが押された」イベント（タイプWM_KEYDOWN ）が配置されます 。 その後、イベントはイベントループによってアクティブなアプリケーションのウィンドウにディスパッチされます。



これらすべてのアクションには時間がかかりますが、私たちの目的（キーボードでの入力）には無視できます。 ここで重要なのは、主要なオペレーティングシステム（つまり、Windows、Mac、およびLinuxベースのオペレーティングシステム）がリアルタイムシステムではないため、遅延値に関する保証がないことです。 ハードウェアプロセス（ネットワークI / O、セーブI / Oなど）とマルチタスクソフトウェアの両方が、予測できないほど（そして無制限に）処理時間を増加させる可能性があります。



ちなみに、GUIアプリケーションはシステムレイテンシに厳しい制限を課す可能性があるため、 Linuxカーネルの計画をデスクトップ使用専用に最適化する試みが数多く成功しています（特にulatencyd動的最適化システムを使用）。



簡単にするために、キーボードから入力するときにコンピューターに大きな負荷がないと仮定します。 この種類の遅延は1ミリ秒未満になります。



仮想マシン



テキストエディター/ IDEがプロセス仮想マシン （JavaのJVMや.NET FrameworkのCLRなど ）上で実行される場合、ランタイムもリアルタイムシステムではないため、追加の遅延が発生する可能性があります（次のような特別な実装を除く） リアルタイムJava ）。



通常、パフォーマンス自体は問題を引き起こしませんが、 JITコンパイラーまたはガベージコレクターをオンにすると、多少の遅延が予想されます。 JavaScriptエンジンとEmacs Lispインタープリターもこのタイプの遅延を引き起こします。



メインの仮想マシンはここ数年で大幅に改善されましたが、安定した遅延を保証するために、いくつかの予備的な「ウォームアップ」が依然として有用である可能性があります。



エディター



この部分が最も重要です。 使用するエディターは、印刷の遅延に大きく貢献します。 ハードウェアによって作成される遅延とは異なり、エディターの最大遅延は実質的に無制限です（1〜2秒で簡単につまずきます）。



エディターは主に中央処理装置に結び付けられているため、より強力なマシンを使用することでエディターの遅延を減らすことができます（優れたグラフィックプロセッサーも役立ちます）。 しかし、電力のみへの希望は完全に正当化されるわけではありません-それはしばしば、それが本当に最も必要とされる間違った場所に行きます（たとえば、開発サーバーを起動するとき、またはバックグラウンドでデータを処理するとき）。 また、一流のラップトップでさえ、 省エネモード（バッテリー）ではるかに遅くなる可能性があるため、このアプローチは部分的にしか効果がないことに注意してください。 さらに、ご存知のとおり、かなり高価です。



より良い方法があります-原則として、静かなタイピングのためにスーパーコンピューターは必要ありません-私たちがしなければならないのは、目標を念頭に置いて、エディターを実装することです。 エディターでの入力は比較的簡単なプロセスであるため、 286プロセッサー上のコンピューターでさえかなり速い入力を提供しました。 IntelliJ IDEAのゼロレイテンシタイピングが目指しているのは、今日の洗練されたIDEでもほぼゼロのタイピングレイテンシを達成することです。 技術的な詳細については、 AWTおよびSwingでの低レイテンシレンダリングに関する私の記事を参照してください（Javaプラットフォームが考慮されますが、主要なアイデアは、グラフィカルユーザーインターフェイスを構築するためのほとんどのオペレーティングシステムとフレームワークに拡張できます）。



エディター/ IDEの印刷遅延は大きく異なります。 次の章には、トピックに関する豊富な経験的情報が含まれています。



レンダリングパイプライン



中央およびグラフィックプロセッサは並行して動作し、ビデオドライババッファで補完された命令バッファを介して相互作用します。 ほとんどのレンダリングコマンドは非同期です。 したがって、レンダリング方法が完了するとすぐに、すぐに開始しないすべての権利があります。 レンダリングコマンドはビデオドライバーバッファーに蓄積され、パッケージ化されてGPU命令バッファーに送信されます（遅延により、より高いフレームレートを取得しようとします）。 結果として生じる遅延は、ハードウェア/オペレーティングシステム/アプリケーションソフトウェアインターフェイス/ビデオドライバーの組み合わせに応じて、わずかなものから非常に大きなものまでさまざまです。



典型的なデスクトップアプリケーションは、グラフィカルユーザーインターフェイスを構築するためのフレームワーク上で実行されるため、下のレンダリングパイプラインから分離されているため、レンダリング（レンダリング）同期から分離されています 。 通常、これは受け入れられる 多くのデスクトップアプリケーションは遅延の影響を受けません。 ただし、一部のアクションは非常に敏感です（IDEでの入力など）。これは、エディターがバッファー内のコマンドを明示的に「プッシュスルー」し、フレームを強制的にレンダリングして待ち時間を短縮できるためです。 例については、OpenGLでの同期の操作を参照してください。 また、コンベアのプッシュに関するデモを見ることができます。



ダブルバッファリング



部分的にトレースされたフレームを表示せず、画面全体に一度に画像全体を表示するために、多くのアプリケーションはいわゆるアプリケーションを使用します。 ダブルバッファリング -画像は最初にオフスクリーンの「セカンダリバッファ」で準備され、すべてのグラフィック操作が完了すると、更新された画像領域がビットごとのコピーまたはページの切り替えによってフレームバッファに転送されます 。 多くのフレームワーク（ Swingなど）は、デフォルトでダブルバッファリングを行います。



言うまでもなく、この追加手順は追加の遅延につながります。 Javaのドキュメントには、「パフォーマンスメトリックが、直接レンダリングと比較してダブルバッファリングまたはページ切り替えが発生する速度だけである場合、失望する可能性があります。 ダイレクトレンダリングの値はダブルバッファリングの値をはるかに上回り、これらの値はページの切り替えの値よりもはるかに高くなることがわかります。



ダブルバッファリングが絶対に必要な場合もあれば、実際には不要な場合もあります。 したがって、編集者は過度の視覚的遅延を避けるために、ダブルバッファリングを慎重に使用する必要があります。 詳細については、 バッファリングのオーバーヘッドのデモをご覧ください。



ウィンドウマネージャー



最近のアプリケーションは、フルスクリーンモードではほとんど動作しません。 ほとんどのデスクトップ環境では、各プログラムが個別のウィンドウに表示されます。 このタスクは、いわゆる ウィンドウマネージャ。ウィンドウの描画および更新方法に応じて、いくつかのクラスに分割できます。



スタックウィンドウマネージャーは、最初に背面にあるウィンドウのレンダリングが実行されるように、重複するウィンドウのイメージを整理します。このアプローチにはいくつかの欠点（ウィンドウのコンテンツを明示的に復元する必要がある）がありますが、アプリケーションがフレームバッファーに直接描画するため、追加の遅延は発生しません。スタックウィンドウマネージャーの例：Windowsのクラシックテーマ、LinuxのOpenbox。



複合ウィンドウマネージャーフレームバッファの代わりに、各ウィンドウに専用のオフスクリーンバッファを使用し、それが適切と思われる場合（および方法）すべてのウィンドウを一緒に表示します。この分離により、必然的に遅延が多少増加します。コンポーネントマネージャの例：WindowsのAero、LinuxのCompiz。



関連する経験的データについては、次の章で説明します。



垂直同期



垂直同期またはV-Syncは、画面の破損を防ぐ方法です、つまりディスプレイが画面の1つの画像のいくつかのフレームからの情報を表示するような状態。結果として生じる歪みは、鋭い垂直エッジを持つ水平方向に移動するオブジェクトで最も顕著です（つまり、印刷中ではありません）。



V-Syncは、セカンダリバッファの内容をフレームバッファに転送する前に、生成されたビデオ信号の新しいフレームを待機することになります（したがって、V-Syncはダブルバッファリングを意味します）。したがって、垂直同期が有効になっている場合、フレームバッファを更新する前に追加の遅延が発生する可能性があります。。最大遅延は約17ミリ秒で、平均は約8ミリ秒です（60 Hzのリフレッシュレートの場合）。興味深いことに、この遅延は画面の更新によるものです。この遅延の一部は回復できないため（シンボルの垂直位置に応じて）、平均合計値が約4ミリ秒しか増加しません。ただし、合計遅延の最大増加は約17ミリ秒に達します。



通常、デスクトップ環境では、V-Syncを有効にするかどうかを明示的に選択することはできません。 WindowsでのV-SyncはAeroでは許可されていますが、Classicテーマでは許可されていません。 Linux V-Syncは、複合ウィンドウマネージャーとスタックウィンドウマネージャーの両方でオフになっているようです。



ある意味では、V-SyncはGPUを強制的にリフレッシュレートの制御に適応させていますが、これはブラウン管時代の遺産です。現在、はるかに好ましい解決策があります（以下を参照）。一般的なコンピューター



の遅延値を考慮します（重要なI / O負荷と計算機はなく、ウィンドウマネージャーはV-Syncなしで使用されると想定しています）。

出所	分、さん	最大ミリ秒	平均ミリ秒
オペレーティングシステム	0	∞	？
仮想マシン	0	∞	？
エディター	0	∞	？
ストリームレンダリング	0	？	？
ダブルバッファリング	0	？	？
ウィンドウマネージャー	0	？	？
垂直同期	0	0	0
合計	0	∞	？

これらの遅延は、ハードウェアによる遅延よりも予測が難しく、コンピューターの構成に非常に敏感です。原則として、合計処理遅延は0〜1ミリ秒または10秒です。そのため、ここでは理論的な考察が十分ではなく、いくつかの正確な数値が必要です。次の章の広範な経験的証拠を参照してください。



処理遅延の状況を改善するにはどうすればよいですか？いくつかの方法があります。



•低遅延エディター/ IDE

•強力なコンピューターハードウェア（中央およびグラフィックプロセッサー）

•スタックウィンドウマネージャー（クラシックWindowsテーマ、Openboxなど）。

•垂直同期の欠如：



明らかに、エディターは最も重要です。

2.3。出力遅延

一般的な非ゲーミングLCDモニターが生成された画像をどのように表示するかを検討してください。



画面の更新



コンピューター画面の画像は、ビデオカードのメモリ（または共有ビデオメモリ）のフレームバッファーに保存されます。モニターは、フレームバッファーに直接アクセスできません。代わりに、ビデオコントローラーは、ビデオインターフェイス（VGA、DVI、HDMI、DisplayPortなど）を介して送信されるビデオ信号を生成するため、モニターは内部イメージバッファーを継続的に更新できます。この送信は、リフレッシュレートと呼ばれる固定レートで行われます。通常のLCDモニターの場合は60 Hzです。したがって、更新に関連する最大遅延は約17ミリ秒であり、平均は約8ミリ秒であると予測できます（新しく入力した文字を表示するだけでよいため、フルフレームの送信に必要な時間は無視できます）。



表示ラグ 着信画像をすぐに表示する必要が



あるCRTモニターとは異なります（その「メモリ」は蛍光体の残光であるため））、LCDモニターには独自の画像バッファーがあります。原則として、これにより、サイズ変更、インターレース解除、または何らかの方法で「改善」するために、着信画像の表示を遅らせることができます（または、ピクセルを更新する前に完全なフレームを取得します）。結果として生じる遅延は、表示遅延（または「モニター入力遅延」）として知られています。この現象は最近広く公表されましたが、それでもかなり議論の余地のあるトピックです。多くの場合、ディスプレイレイテンシの測定値は正しくありませんこの遅延をピクセル応答時間から分離するのは困難です（適切な方法については、Pradの入力遅延に関する優れたレポートを参照してください））最悪の場合、遅延は2〜3フレーム（つまり、60 Hzのリフレッシュレートで最大50ミリ秒）になる可能性がありますが、入力遅延はコンピューターモニターではなく、主に高解像度テレビで表示されます。したがって、この遅延は通常のモニターではゼロに近いと想定できます。ただし、モニターのすべての「画像補正」をオフにすることをお勧めします（奇妙なことに、オーバードライブも）。



応答ピクセル



ピクセルのLCDディスプレイは、直ちに制御電圧の変化に応答しないことがあります。ディスプレイ上のピクセルを変更するのに必要な時間間隔は、ピクセル応答時間と呼ばれます。。この時間は、主にLCDマトリックステクノロジー（TN、IPS、VAなど）に依存します。LCDモニターは大きな進歩を遂げ、ピクセルの応答時間を短縮し、最新のTNモニター（現在最も広く使用されている）の平均応答時間はわずか4ミリ秒です。



それでは、典型的なコンピューターモニターの遅延値を収集しましょう。

出所	分、さん	最大ミリ秒	平均ミリ秒
画面更新	0	17	8
表示遅れ	0	？	0
ピクセル応答	？	？	4
合計	？	？	12

出力遅延を減らすことは可能ですか？ここには、いくつかの信頼できる方法があります。



•ゲームモニター。ディスプレイの待機時間を短くし、ピクセル応答を高速化します。

•144 Hzのリフレッシュレートのモニター（アップグレードに関連する遅延は3.5ミリ秒です）。

• 動的リフレッシュレート（最大240 Hz）および同期更新を備えたAdaptive-Sync、FreeSyncまたはG-Syncをサポートするビデオカードとモニターの組み合わせ。



これらのすべての手段により、全体的な出力遅延を約10％に減らすことができます。1-2ミリ秒。

2.4。完全な遅延

印刷遅延のすべてのコンポーネントの平均遅延を要約します。

出所	通常、ms	パーフェクト、ms
ログイン	14	1
処理中	？	0
出口	12	2
合計	？	3

典型的なキットは、通常の非ゲーミングキーボードと従来のLCDモニターで構成されています。理想的な構成には、低遅延のキーボードとモニター（ゲーム）が含まれます。



入力および出力遅延成分は、高精度で推定できる定期的なハードウェアプロセスによって厳密に決定されます。これらの遅延は、中央およびグラフィックプロセッサのパフォーマンスに依存せず、予測可能な上限があります。キーボードとモニターを合わせた一般的な平均遅延は約26ミリ秒であり、それ自体はそれほど大きくありませんが、処理遅延に追加すると、エディターの遅延がより顕著になります。 I / Oレイテンシ自体でさえ、人間の知覚のしきい値をすでに超えています。



処理遅延は、入力/出力遅延とは対照的に、主に中央およびグラフィックプロセッサの計算によって決定されるため、ハードウェアに依存し、ほとんど無制限の最大値を持ちます。処理遅延を予測できません。このデータを取得するには、適切な比較テストが必要です。理論的には、理想的な処理遅延は0〜1 msに近い場合があります。



問題のチェーンのすべての部分が重要ですが、エディターは最も弱いリンクであり、印刷の遅延に主に寄与しています。

3.エディターの比較テスト

処理遅延の測定を試すために、テキストエディター（ソース）の視覚的な遅延を決定および分析するためのツールであるTypometerを用意しました。Typometerは、OS入力イベントを生成し、スクリーンショットを取得して、キーストロークと対応する画面更新の間の遅延を測定します。したがって、測定は処理遅延のすべてのコンポーネント（つまり、OSキュー、仮想マシン、GPUストリーム、バッファリング、ウィンドウマネージャー、および可能な垂直同期）をカバーします。すべてのコンポーネントは本質的にエディターと織り交ぜられており、原則としてエディターがそれらに影響するため、このアプローチは正しいです。

3.1。 構成

テストに使用したハードウェアとソフトウェアの構成については、次を参照してください。



ハードウェア：



•CPU：Intel Core i5 3427U、1.8 / 2.8 GHz、3MBキャッシュ

•グラフィックス：Intel HD 4000（ドライバーv10.18.10.3958）

•メモリ：4 GB DDR3

•ディスプレイ：1920 x 1080、32 ビット、59.94 Hz



ソフトウェア：



• Microsoft Windows 7 HP x64 SP1 6.1.7601

• Lubuntu Linux 15.10デスクトップamd64

• Windows上のVirtualBox 5.0.10（デフォルト設定、フルスクリーン）モード）



エディター：



• Atom 1.1

• Eclipse4.5.1

• Emacs 24.5.1

• Gedit 3.10.4

• GVim 7.4.712

• IntelliJ Idea CE 15.0

• Netbeans 8.1

• Sublime Text 3083



比較テストは同じハードウェアプラットフォームおよび同じハードウェアプラットフォームで実行されるため、各エディターの同じバージョンでは、結果を直接比較できます。結果は構成によって異なる場合があるため、比較テストでは、かなり典型的なセットを使用しました（非常に遅くはありませんが、あまり強力ではありません）。これにより、結果がより代表的になります。



少なくとも構文の強調表示を提供するエディターのみが選択されました。メモ帳は間違いなく最速の応答エディターですが、実用的なエディターと比較するのは不公平でしょう。



さらに、中エディタの例を除外し、端末自体の端末が大幅に印刷遅延に影響を与えることができるよう、。ちなみに、最新のOSはリアルテキストモードをサポートしなくなりました。Windowsコンソールと仮想Linuxコンソール（Alt + Fn経由）の両方がグラフィックフレームバッファーの上にモデル化されています。



分析は、で行ったR。グラフはggplot2を使用して表示されました 。

3.2。 方法論

すべてのエディター/ IDEはデフォルト設定で機能し、アプリケーションウィンドウは最大化されました。



エディターは、空のテキストファイルまたはXMLファイル（より正確には、 Mavenスキーマ ）のいずれかで動作しました。 すべてのエディターで強調表示され、他のプロジェクトファイルから独立しているため、XMLが選択されました。



Typometerは次のパラメーターを使用しました。



•文字数：200

•遅延：150ミリ秒

•アクセス：ネイティブ

•モード：同期



150ミリ秒の遅延が選択されたのは、かなり速いタイピングでのキーストローク間の平均時間間隔を表すためです（最小間隔は40ミリ秒です）。 正確な値は大きな役割を果たしません。なぜなら、 Typometerは、次のシンボルを一時停止して印刷する前に、シンボルが表示されるのを同期モードで待機します。



前述のように、Aeroで実行される合成はレンダリング遅延を増加させ、垂直同期を強制するため、クラシックウィンドウマネージャーがWindowsで使用されました（テストにより、Aeroテーマによってすべてのエディターの影響が軽減されることが示されました）。 ClassicテーマとAero（16.68および33.37ミリ秒の破線）でのGVimテスト（一般に最速のエディターの1つ）の比較を次に示します。



描画遅延に対するWindows Aeroの影響（GVim）





Aeroが少なくとも1つのフレーム遅延（60 Hzのリフレッシュレートで約16.7 ms）を導入し、タイムサンプリングにつながることがわかります。 これにより、エディターの内部パフォーマンスが隠され、ベンチマークプロセスが歪められます。 前に指摘したように、垂直同期によるビデオ遅延はフレームバッファーの遅延よりもわずかに小さくなりますが、平均差はわずか4ミリ秒であり、最大追加遅延はまだ17ミリ秒（60 Hzの場合）です。 その効果は非常に大きいため、 人々はしばしば 、人の反応の持続時間のテストで「裸眼」による追加の遅延を見つけます 。



グラフは、タイポメーターの遅延測定精度が非常に優れていることも示しています。低い値は理論上の16.68335に非常に近いため、数学的な計算の結果のように見えます。



Linuxに関しては、同じ理由でLubuntuがUbuntuよりも好まれました-Compizはアプリケーションのレンダリングに追加の遅延を提供します。 これがグラフです（中央線付き）：



Linux Compizのレンダリング遅延への影響（GVim）





平均挿入遅延は約です。 8 ms。これはAeroの値よりも優れています。 同期による離散化もありません（ただし、ジッタの増加がここで観察されます）。 V-Syncは使用されないため、ビデオ遅延はフレームバッファーの遅延レベルになります。 より高い測定精度を得るには、スタックウィンドウマネージャー（Openboxなど）を使用することをお勧めします。



メモ帳などの最速のアプリケーションで測定された遅延が1ミリ秒未満で安定していることを考えると、測定ツールが十分な精度と再現性を提供すると仮定することは正当化されるようです。 フレームバッファと出力ビデオ信号間の接続は確定的であるため、結果は代表的なものと見なすことができます。



さまざまな観測された依存関係にもかかわらず、次の典型的な時系列を区別できます。



典型的なエディター遅延時系列





単純なエディターは非常に安定したレイテンシー値を示しますが、平均は比較的大きくなる場合があります。



高度なエディター（および仮想マシン/インタープリター上で実行されるエディター）は、平均レイテンシが高いことに加えて、レイテンシのばらつき（ジッタ）が高くなる傾向があります。



安定した遅延値の間隔がランダムな外れ値によって定期的に中断される場合、中間の動作も一般的です。 場合によっては、遅延が傾向を示し、水平方向の文字の配置に関するエディターのアルゴリズムへの線形依存を示します。

3.3。 窓

遅延分析手法の概要として、遅延を測定しない方法に関する大きな議論を参照することをお勧めします 。これは、遅延の測定値として平均値が中央値よりも優れている理由と最大値が非常に重要である理由を説明しています。



テキストファイル



ファイナルテーブル（平均遅延でソート）を見てみましょう。 ここでのRMSは、 ジッタの尺度として使用される標準偏差を意味します 。 ここでは、「理想的な」状況が示されていることに注意してください-コードを強調表示しない単純な空のファイル。 他の構成では、定義上、待ち時間が長くなります。



Windows Editor Delay（テキストファイル）：

エディター	分、さん	マックス・ミズ	平均ミリ秒	MSE、ms
グヴィム	0.2	1,2	0.9	0.2
IDEA（遅延ゼロ）	0.1	21,2	2.9	2.7
メモ帳++	0.1	5.9	4.3	0.8
Emacs	4.2	19,2	5.3	1,1
崇高なテキスト	6.2	35,2	8.2	2.0
日食	0.1	20.8	10.1	1,6
Netbeans	7.3	31.6	11.8	3.9
アイデア	0.1	83.7	24.7	12.0
アトム	29.2	85.5	49.4	7.2

ファイナルテーブルは、遅延の分布を概算するだけの機会を与えてくれるので、適切な、より詳細なグラフィックで補足することが有用です。 従来のヒストグラムは 、複数のデータセットを比較するにはあまり便利ではありません。 スパンチャート （「口ひげボックス」）はあまりにも粗野です。 高音部音部記号の方が優れていますが、統計に専門的に関与していない人にはかなり奇妙に見えます。



より便利な方法があり、見た目も良くなっています。水平軸に値をグラフィカルに表示し、ランダムな垂直シフトを追加して分布を表示できます（このアプローチに関する追加情報があります）。 結果のグラフはシンプルでわかりやすく、さまざまなデータセットを比較できます。



Windows Editor Delay（テキストファイル）





明らかに、エディターは同等に作成されません（少なくとも遅延の点では）。



まず、平均レイテンシは大きく異なります-シンプルなエディターはレイテンシが低い傾向があります。 勝者はGVimですが、遅延ゼロを有効にしたIDEAはGVimに非常に近いです。 すべてのJVMベースのエディター（デフォルトモードのIDEAを含む）は下部にあります。これは予測可能であり、Atomに次いで2番目です。 Chromeのパフォーマンスはさらに低下しました。



もう1つの顕著な違いはジッターです。「軽い」エディターは非常に安定した遅延を示しますが、複雑なエディターははるかに広い範囲の値を持ちます。 デフォルトモードのIDEAは、最大値が最大の最大遅延スプレッドを示します。



以下のヒストグラムは、IntelliJ IDEAのゼロ遅延モードの詳細な効果を示しています。



Windowsでのゼロ遅延モードの影響（テキストファイル）





ゼロ遅延モードにはプラスの効果があり、平均遅延が減少し、ジッターが除去されます（完全ではありません）。



XMLファイル



前のセットが「人工的」すぎることは明らかです。 最後に、構文の強調表示なしで空のファイルを編集するには、メモ帳を使用できます。 より深刻なものについては、別のエディターを使用してください。 比較的大きなXMLファイルを入力して、値がどのように変化するかを見てみましょう。



エディターの遅延に対するコンテンツタイプの影響（Windows）





わあ！ 違いは非常に顕著であると同時に異常です。 一部の編集者-ゼロ遅延モードのGVimとIDEA-まあ、ちょうど、「タフな男」、彼らは「ドラム」です。 ただし、ほとんどのエディターでは、遅延は均等に増加しました。 IDEAの平均遅延はわずかに減少しましたが （これは少し奇妙ですが）、最大が増加しました。 最も強力な変化はEmacsで起こり、その遅れは空に向かって急上昇しました。



省エネ



ここで、電源から切断し、省電力モードのバッテリーで動作します。



Windowsエディターの遅延（XMLファイル、省電力）：

エディター	分、さん	最大ミリ秒	平均ミリ秒	MSE、ms
グヴィム	0.6	2.9	1.4	0.2
IDEA（遅延ゼロ）	1,5	58.7	4.3	7.4
メモ帳++	4.8	26.1	9.8	1.3
崇高なテキスト	10,4	19.3	12.6	0.7
日食	13.9	60,4	19.0	5,0
アイデア	13.6	239.3	45.5	39.6
Emacs	46.1	77.4	50,5	4.3
Netbeans	11.9	138.1	59.0	21,2
アトム	48.9	104.0	60,4	7.0

これが遅延にどのように影響したかをさらに詳しく考えてみましょう。



エディターの遅延に対する省電力モードの影響（Windows、XMLファイル）





ほとんどの編集者は目立ちませんでしたが、いくつかの注目すべき例外があります：IDEAとNetbeans。 IDEAでは、最大遅延は240ミリ秒に急上昇しました。これは明らかに、「知覚性」のしきい値を超えています。



ゼロ遅延モードがこれらの条件にどのように影響するかを示します。



Windowsのゼロ遅延モードの影響（XMLファイル、省電力）





繰り返しますが、ジッターを完全に除去するわけではありませんが、その影響は大きいです。

3.4。 Linux

簡単にするために、空のファイルを使用した合成テストをスキップして、Linuxでの観察を続けます。



Linuxエディターの遅延（xmlファイル）：

エディター	分、さん	最大ミリ秒	平均ミリ秒	MSE、ms
IDEA（遅延ゼロ）	0.8	3.9	1.7	0.5
グヴィム	1.7	8.4	4,5	1.4
Gedit	5,0	24.2	12,4	3.0
Emacs	7.5	46.3	20.3	4.1
崇高なテキスト	9,4	35,4	23.1	5.2
Netbeans	8.4	92.7	24.5	12.9
アトム	16,0	59.6	32,5	8.4
日食	23.6	87.1	46.5	14.0
アイデア	10.1	198.0	69.2	27.1

詳細な遅延分布の追加図：



Linuxエディターの遅延（xmlファイル）





Windowsでの以前の結果との比較：



エディターの遅延に対するOSの影響（XMLファイル）





一般的な機能は、ほとんどのエディターでLinuxのジッターが著しく高いことです（ジッターが実際に減少したIDEAのゼロ遅延モードを除く）。



EmacsとAtomがLinuxで勝ちます-ここでの平均レイテンシは著しく短くなります。



一方、GVim、Sublime Text、Eclipse、およびIDEA（デフォルトモード）では、Linuxのレイテンシが大幅に増加しました。 IDEAは最大の効果を経験しました-通常の電力モードでも最大遅延は200ミリ秒に達しました。 Eclipseの反応時間も深刻な影響を受けています。



IDEAでのゼロ遅延モードでの印刷は、もちろん勝者です（ここでは、IDEAはGVimよりも優れていました）。



Linux Zero Delay Impact（XMLファイル）





Linuxのゼロ遅延モードは、非常に安定した低遅延を示します。

3.5。 Virtualbox

たとえば、主にゲーム用にWindowsを使用し、Linux仮想マシンで作業していると仮定します（実際、なぜですか？）。 この使用状況でエディターの変更はどのように遅延しますか？ 見てみましょう。



Linuxの遅延エディター（VirtualBox、XMLファイル）：

エディター	分、さん	最大ミリ秒	平均ミリ秒	MSE、ms
IDEA（遅延ゼロ）	4.2	29.7	12,4	4.9
グヴィム	6.0	26.0	18.3	4.1
Gedit	19.5	47.6	30.1	4.8
Emacs	27.6	68.3	33.8	7.4
崇高なテキスト	31.5	58.2	46.1	5.2
Netbeans	12.6	159.9	46.7	19.5
アトム	29.1	89.4	62.6	10,2
日食	45.3	131.4	79,4	13.7
アイデア	29.2	347.8	87.5	42.0

以下は、以前の「自然な」結果との比較です。



エディターの待ち時間に対する仮想化の影響（Linux、XMLファイル）





遅延の離散化（垂直同期または別の種類の離散バッファ同期のいずれかにより発生）に加えて、すべてのエディターで一定の遅延の増加が見られます。 分布はあまり変化せず、簡単に説明できます（基本的なアルゴリズムは視覚化中に保持されます）。 IDEAの最大遅延は350ミリ秒に増加しました。



省エネ



完全な画像を取得するには、バッテリーに切り替えます。 VirtualBoxでの省電力モードは、おそらくエディターを遅延させる最も強力な組み合わせです。



Linuxエディターの遅延（VirtualBox、XMLファイル、省電力）：

エディター	分、さん	マックス・ミズ	平均ミリ秒	MSE、ms
IDEA（遅延ゼロ）	4.3	69.6	11.9	8.9
グヴィム	5,0	35.8	19.0	3.8
Gedit	13,4	49.3	23.9	6.0
Emacs	19.6	79.5	44.7	6.9
崇高なテキスト	38.1	65.0	52.1	7.3
アトム	70,2	152.2	90.0	13.7
Netbeans	35.7	344.7	119.1	43.3
日食	99.3	269.6	133.6	36,2
アイデア	119.4	544.6	198.8	63.1

まあ、そのような遅延はばかげています！ 最大遅延は0.5秒を超えました。



明確にするために、これらのデータを理想的な条件下での結果と比較してみましょう。



エディターの遅延に対する構成の影響





明らかに、構成は、結果として生じるエディターの遅延において重要な役割を果たします。 ただし、編集者の反応は異なります-一部の作業は深刻な障害を受ける可能性があり、他の作業はほとんど効果がありません。



ゼロ遅延オンのIntelliJ IDEAは最高の耐久性です。 最も困難な状況でどのように見えるか見てみましょう：



VirtualBoxのヌル遅延モードの影響（Linux、XMLファイル、省電力）





興味深いことに、ゼロ遅延モードでは、IntelliJ IDEAは他のすべてのエディター（さらに、コンソールエディターも）よりも優れています。

4.結論

もちろん、印刷するよりも印刷する方がはるかに重要です。 ただし、低レイテンシの視覚的フィードバックにより、多くの場合、このプロセスがより効率的で楽しくなります。



•レスポンシブエディターを使用します。

•低遅延のキーボードを使用します。

•モニターのすべての「イメージエンハンサー」をオフにします。

•OSでスタックウィンドウマネージャーを有効にします。



喜んで印刷してください！

5.参照

こちらもご覧ください：



• Typometer-テキスト/コードエディターの視覚的な遅延を測定および分析するためのツール。

• AWTおよびSwingでの低レイテンシレンダリングプロセス -AWTおよびSwingアーキテクチャの遅延ソースの詳細な分析、レンダリングレイテンシを大幅に削減する方法。