翻訳者から：遅いソフトウェアの問題は、ここ数週間でHabréとHacker Newsでの議論の主要なトピックの1つになりました。 たとえば、Nikita Prokopov の記事「ソフトウェアの失望」と2432件のコメントを参照してください。



コンピューターで多くの時間を費やしています。 アプリケーションを起動してWebページをロードするたびに待機しています。 どこにでもスピナーまたは砂時計のアイコンがあります。 Ironはより強力になっていますが、ソフトウェアはまだ遅いようです。 なぜそう



コンピューターを使用して重要な作業を行う場合、高速ソフトウェアに値します。 多くの場合、最新のソフトウェアはこれらの要件を満たしていません。 Ink＆Switchの研究室では、この状況の理由を調査しましたが、ソフトウェアは最終的に改善されました。 この記事は私たちの研究の結果を発表しました。

目次

• 正確には遅さはどこですか
  
  
  • 遅延は帯域幅ではありません
  • タッチインターフェース
  • キーボード
  • マウス
  • 用途
• 減速はどこから来ますか？
  
  
  • 入力機器
  • サンプリングレート
  • ディスプレイとGPU
  • オーバーレイループ
  • ランタイムのオーバーヘッド
  • 故意の遅延
  • 敵対的なエージェント
  • アプリケーションコード
  • すべてをまとめる
• 高速ソフトウェアへ
• 文学

正確には遅さはどこですか

ユーザーは「遅い」プログラムとして何を認識していますか？ 時々、ソフトウェアは私たち全員に遅延と遅れを悩ませます。 しかし、これらの問題をよりよく理解するには、この質問に厳密に答える学術研究で直感的な感覚を補う必要があります。



知覚速度は、待ち時間の概念と密接に関連しています。 「遅いと思われるもの」の科学的研究とこれらのアプリケーションの実際の遅延の測定を比較すると、すべてがどれほど悪いかが明らかになります。

遅延は帯域幅ではありません

ソフトウェアのパフォーマンスについて議論するとき、帯域幅についてよく耳にします。 たとえば、「このWebサーバーは毎秒10,000リクエストを実行できます。」 しかし、それはユーザーが物事を認識する方法ではありません。 特定のWebリクエストにかかる時間、ドキュメントを開くのにかかる時間、またはアプリケーションがマウスクリックに応答する速度に関心があります。 これらの相互作用は、待ち時間に関連付けられています。 遅延は、この記事で検討する重要な指標です。



ユーザーの認識

インタラクティブシステムでのレイテンシの重要性の詳細については、 こちらを参照してください 。



他の要因がソフトウェア速度の感覚に影響します。 たとえば、長いタスク中のフレームレートとフィードバック。 しかし、レイテンシは基本的な指標であり、レイテンシが非常に低いと、ソフトウェアは非常に高速に感じると考えています。

タッチインターフェース

まず、タッチスクリーンの遅延に対する人間の感受性を考慮します。



研究者は、ユーザーが知覚する遅延を正確に判断するテストでこれを検証します。 最初に、被験者には（たとえば）1ミリ秒の遅延を持つインターフェイスが提供され、次に（たとえば）70ミリ秒の遅延があり、ボタンを押すなどの操作を実行するように求められます。 70ミリ秒のインターフェイスが1ミリ秒のインターフェイスよりも常に悪い結果を示す場合、70ミリ秒は「顕著な差」と呼ばれます。



わずかな顕著な差

遅延と関連する実験設備の最小の顕著な違いの詳細については、例えば、 この作品を参照してください。



最小の顕著な違いは予算です。その後、特定の操作がユーザーにとって遅く感じ始めます。



たとえば、画面上でアイテムをドラッグすると、ユーザーはわずか2ミリ秒の遅延しか感じません。 最も目立たない遅延は、ユーザーと実行されているアクションによって異なりますが、常に非常に低い値です。



ドラッグアンドドロップの知覚

スタイラスでドラッグすると、知覚レポートは2〜16ミリ秒になります 。

指でドラッグすると2〜11ミリ秒 。

指でドラッグした場合、平均11ミリ秒 。



タブレット上でスタイラスを使用して描画する場合も、同様の結果が得られました。 ここで、研究者は、ユーザーが20〜80ミリ秒の遅延に気づくよう提案しました。 独自の非公式のテストでは、約80ミリ秒の遅延が非常に顕著であると見なされており、手書き中にスタイラスが反応するようになるには20ミリ秒にかなり近い時間がかかります。



スタイラス遅延知覚

スタイラスで書くときの10〜70ミリ秒の遅延の知覚に関するレポート 。

スタイラスを使用したさまざまなアクションで21〜82ミリ秒 。



短い手書きレイテンシと高い手書きレイテンシの違いは、比較すると明らかです。



左：エンドツーエンドのレイテンシが約15ミリ秒のiPad ProおよびNotesアプリ。 右：約70ミリ秒の遅延があるSamsung S3およびOneNoteアプリ。 ビデオが16倍遅くなります。



タッチデバイスでの別の典型的な操作は、ボタンまたはリンクをクリックすることです。 ここでは、テストにより、ユーザーは70ミリ秒のターンあたりの遅延に気づくことが決定されました（ただし、一部のユーザーではおそらくそれよりも低いでしょう）。



画面のタップ遅延の知覚

この研究により、平均最小遅延は69ミリ秒であることが明らかになりました。



次に、2つの異なる遅延を比較する例を示します。



左：約90ミリ秒の遅延でiPhone 6sの設定タブを開きます。 右：Samsung S3の設定を約330ミリ秒の遅延で切り替えます。 ビデオが16倍遅くなります。



最新のアプリケーションはこれらのしきい値をどのように満たしていますか？ ドラッグアンドドロップについて話すと、すべての消費者を満足させるために数ミリ秒の遅延に常に対応できる商用システムはありません。



ドラッグアンドドロップのパフォーマンス

以下で説明するように、データ入力用のディスプレイや機器でさえ、ソフトウェアのいくつかの層は言うまでもなく、10ミリ秒の予算に収まりません。



したがって、タッチスクリーンで現在のすべてのオペレーティングシステムを使用している場合、少なくとも一部のユーザーは、ドラッグするときにオブジェクトが指の後ろにあると感じるでしょう。



スタイラスを使用して描画する場合、少数のシステムは許容可能な低レベルの遅延に近づきます。 しかし、それらのほとんどはこれらの値よりもはるかに高く、これはユーザーによって大幅な遅延として予想されます。



以下は、さまざまなデバイスのタブレットのスタイラスを使用した描画の遅延に関するInk＆Switchテストの結果です。 画面との接触から対応するピクセルの色の変化の開始までの平均遅延は、5ミリ秒に最も近い値に丸められます。

装置	プログラム	遅延（ミリ秒）
iPad Pro	注釈	20
	グッドノート	30
	フラッター	35
Surface Pro	OneNote	25
	スケッチパッド	30
	キャンバス	60
Pixelbook	イカ	40
	キャンバス	60
サムスンS3	イカ	60
	フラッター	65
	キャンバス	75
	ライブボード	80

すべてのデバイスの遅延に関するデータはありませんが、上記のスタイラスの描画遅延に匹敵すると想定しています。



描画遅延とクリック遅延

どちらの場合もタッチ入力が使用される、つまり画面の更新サイクルがアクティブになるため、これらの遅延は同等になると予想されます。 ただし、いくつかの違いがあるため、値がまったく同じになることはほとんどありません。



ここでは約70ミリ秒の遅延が認識できるため、ほとんどのシステムはクリックに対して適切に応答できます。 しかし、システムの理論的な能力よりもはるかに悪い動作をするアプリケーションを見つけることも簡単です。



一般に、感覚システムは、応答性を感じさせるために非常に低いレイテンシを持たなければなりません。 ほとんどのデバイスとアプリケーションは、このレベルのパフォーマンスを提供することができないため、それらはすべて、さまざまな程度で、ユーザーにとって遅いと感じています。

キーボード

入力遅延の増加がユーザーエクスペリエンスを損なうという証拠がいくつかあります。



入力遅延の影響

この研究では、ランダムな遅延がキーストロークに追加され、入力パフォーマンスが低下しました。 ただし、評価した遅延の範囲は1つだけです。 さらに、この研究の著者は、経験豊富なタイプセッターが待ち時間の増加に適応できることを示唆しています。



ただし、最も目立たない入力遅延を具体的に測定する研究については認識していません。 タッチスクリーンを押す遅延（約70ミリ秒）は、指を個別にタッチしてから画面が視覚的に更新されるまでの時間も測定するため、有用なガイドになります。



以下は、さまざまなマシンでのキーストロークの開始からキャラクターの登場までのエンドツーエンドのキーボード遅延の非公式の測定値です。 出典： 「コンピューターの待ち時間：1977-2017」 、インクおよびスイッチのテスト。

パソコン	遅延（ミリ秒）
アップル	30
コモドールペット4016	60
iMac g4 OS 9	70
Macbook Pro 2014	100
カスタムHaswell-e 24Hz	140
サムスンS3	150
Powerspec g405 Linux	170
Symbolics 3620	300

キーボードレイテンシの影響を正確に測定することは、冒険好きな研究者にとって素晴らしい実験になるでしょう。 いずれにせよ、多くのユーザーにとって、キーボードから入力する際の顕著な遅延のしきい値は100ミリ秒未満であると思われます。 おそらくずっと低い。

マウス

レビューの最新タイプの入力デバイス。 ある実験では、ユーザーはマウスの遅延を34〜137ミリ秒、平均65ミリ秒と認識していることがわかりました。



マウスごとに遅延値は大きく異なります。 一部のシステムでは、高性能機器と慎重な低レベルプログラミングを組み合わせることにより、10ミリ秒未満の値が表示されます（ この設定は約8ミリ秒の遅延を表します）。 さらに、マウスとディスプレイの間に追加の遅延またはバッファを導入する平凡な機器とアプリケーションの組み合わせで100ミリ秒を超えることができます。

用途

アプリケーションレベルの遅延は、Webページの読み込みなど、特定のアプリケーションアクションの実行にかかる時間を測定します。 このような遅延の例としては、NYTimes Webページの読み込みがあり、これには約3000ミリ秒かかります。





アプリのアクションが高速に見えるのはいつですか？ 彼らの行動は単純なデータ入力よりも複雑で多様であるため、確実に言うのは困難です。 おそらく、答えはユーザーの期待にも依存します（現在、通常、人々は遅いソフトウェアで作業しています）。 しかし、おおよその数を計算できます。



遅延文献

さまざまなアプリケーションのユーザーに対する遅延の影響に関する文献レビューを参照してください。 これは、トピックに深く没入するための良い出発点です。



基準値の1つは、画面をクリックしたときの上記の最小遅延としての典型的な70 msメトリックです。 リンクをクリックしてからクリックインジケータを表示するまでの遅延に気づいた場合、Webページをクリックしてから開くまでに同様の遅延があることに気付くはずです。



別のリファレンスは、Google RAIL Developer Modelです。 このモデルの作成者は声明をいかなる形でも実証していませんが、このモデルは、100ミリ秒以内の応答が「瞬間的」であり、遅延が「アクションとリアクションの関係を[破る」と主張しています。



端末で自分の感度を非公式に確認できます。 お気に入りのコマンドラインプログラムを実行し、実行時間を測定する 'time'パラメーターを使用して実行します。 確かに15ミリ秒（優れた！）と500ミリ秒（明らかに遅い）の回答の違いに注目してください。







最後の基準点として、視覚刺激に対する典型的な人間の反応時間は約220 msであることを考慮します。



反応には観測だけでなく、後続のアクションも含まれるため、この値は顕著な遅延よりもはるかに大きくなります。



人は無意識の生理学的レベルで遅延の増加を知覚できるという一部の研究者の結論を考慮することも必要です。

実際のアプリケーション

実際のアプリケーションはこれらのガイドラインにどのように適合しますか？ いくつかは対処しています。 たとえば、多くのUnixコマンドラインプログラムは100ミリ秒よりも高速に実行されます。



しかし、ほとんどのインターネットアプリケーションは範囲外です。 約1000ミリ秒のGoogle検索は、ほとんどのWebアプリケーションよりもはるかに高速ですが、コマンドラインでの100ミリ秒未満と比較すると、依然として著しく低速です。 また、良好な接続であっても、5000ミリ秒よりも長く読み込まれるページの例を見つけるのは簡単です。



モバイルおよびデスクトップコンピューターの場合、iOSの組み込みの計算機など、常に100ミリ秒未満の遅延を示すアプリケーションがいくつかあります。 ただし、ローカルですべてのデータを使用できる（または使用する必要がある）場合でも、このしきい値をはるかに超えるアプリケーションの例を見つけるのは簡単です。 Slackの例を考えてみましょう。



次のビデオは、iPad Proの同じワークスペースで2つの低音量チャンネルを切り替えるのに約220ミリ秒かかることを示していますが、iPad Proは間違いなく世界で最もパフォーマンスの高いモバイルデバイスです（ビデオは8倍遅くなります） ）：





アクション遅延などの広範な分野のすべてのプログラムについて一般的な結論を出すことは困難です。 それでも、一部のアプリケーションは十分に迅速にアクションを実行し、ユーザーにとっては瞬時に見える（100ミリ秒未満）のは明らかですが、多くのアプリケーションはそうではありません。

減速はどこから来ますか？

したがって、多くのプログラムの実際の動作が遅いことがわかりました。 このすべての時間はどこに行き、何を最適化できますか？ チェーンの最初のコンポーネントである入力デバイスから始めて、この問題を検討してください。

入力機器

物理的な入力データを画面上の更新に変換するパイプラインの最初のステップは、入力データの処理です。タッチスクリーン、キーボード、またはマウスとの接触をオペレーティングシステムのデジタル信号に変換します。 ここでは、このステップにかかる時間を調べます。



キーボードから始めましょう。 この表は、キーストロークの開始からUSBハブの信号までの測定された遅延を、5ミリ秒に丸めて示しています（ ソース ）。

キーボード	遅延（ミリ秒）
アップルマジック	15
ダス3	25
Kinesis freestyle2	30
エルゴドックス	40
キネシスの利点	50
Logitech MK360	60

ご覧のように、これらのキーボードは、処理パイプラインの最初のステップで予算から数十ミリ秒かかります。 これは、100ミリ秒以下の合計予算からです！ このトピックの詳細については、 「楽しみながら印刷する」を参照してください。



マウスも同様に予算から数十ミリ秒かかります。 最も高性能なゲーミングマウスの遅延は10ミリ秒未満ですが。 押下に対する応答のデータもさまざまです。ここでも、個々のインスタンスは10ミリ秒未満の結果を示しています（ 例 ）。



モバイルデバイスでは、入力デバイスが他のハードウェアコンポーネントと緊密に統合されているため、入力デバイスの遅延の割合を測定することはより困難です。 ただし、入力デバイスの機器の一般的なパターンのいくつかを使用して、遅延とスタンドアロンデバイスを評価できます。

サンプリングレート

一般的なパターンの1つはサンプリングレートです。 多くの入力デバイスでは、機器は定期的に入力を「スキャン」または「サンプル」します。 たとえば、一般的な民生用タッチスクリーンは60 Hzの周波数で動作します。つまり、約17 msごとにセンサーをポーリングします。 これは、最悪の場合、入力デバイスの遅延が少なくとも17ミリ秒、平均で8ミリ秒以下になることを意味します。



すべてが等しい場合、スキャンレートを高くすると入力遅延が減少します。 たとえば、Appleの高度なタッチスクリーンとスタイラスは、60 Hzを超える周波数で動作します（ Appleドキュメントアーカイブからの情報）。

装置	タッチスクリーン（Hz）	スタイラス（Hz）
iPhone 6	60
iPhone 7	60
iPhone 8	60
iPhone X	120
iPad Air 2	60
iPad Mini 4	60
iPad Pro	120	240

同様の遅延の原因はUSBポーリングです。 USBプロトコルはキーボードから入力を受け取るため、キーボードはクリックに関する情報を送信するためにUSBポーリングを待機する必要があります。 低速USBポーリングは125 Hzで実行され、必然的に最大8ミリ秒を導入します。 〜4 msの平均遅延。 1000 Hz以上の周波数でのUSBスキャンの後のバージョンは、遅延の影響を最小限に抑えます。



入力デバイスには、接触バウンスなど、他の多くの潜在的な遅延源があります（詳細については、 バウンスのソフトウェアおよびハードウェアの影響に関する記事「キーボードマトリックスと接触バウンスのスキャン」を参照してください）。



ここではこれらすべてのニュアンスを考慮しませんが、主な点を強調します。a）入力デバイス自体は、ソフトウェアで処理が行われる前に大幅な遅延を引き起こす可能性があります。 b）これはいくつかの個別の理由による可能性があり、遅延時間が加算されます。

ディスプレイとGPU

コンベアのもう一方の端にあるハードウェアは、ディスプレイとビデオカードです。



ここでの遅延の原因の1つは、表示フレームレートです。 ディスプレイは常に再描画できないため、上記の入力デバイスのポーリングと同様の避けられない遅延が発生します。 画面が（たとえば）20ミリ秒ごとに更新される場合、最悪の場合は20ミリ秒、平均で10ミリ秒の遅延が追加されます。



運動知覚

他の要因は、画面上を移動するオブジェクトの認識に影響します。 ブラーバスターズは、このテーマに関する優れたリソースです。 たとえば、 LCD Motion Artifacts 101を参照してください。



ほとんどのディスプレイは60 Hzで動作しますが、プロ仕様のデバイスとゲーム用ディスプレイは120 Hz、144 Hz、および240 Hzで動作します。 したがって、通常、ディスプレイフレームレートのみが遅延に平均約8ミリ秒を追加しますが、最高のフレームレートのディスプレイでは数ミリ秒に減らすことができます。



ディスプレイからの遅延へのもう1つの寄与は、新しいデータを受信した後にピクセルの色を物理的に変更するのにかかる時間です。 この時間は、ハイエンドゲーミングディスプレイの数ミリ秒から、応答性の低いLCDの2桁の値までさまざまです。



応答時間を表示する

このパラメーターを測定することは困難ですが、いくつかの実例となるデータはNotebook Check Webサイトで入手できます。 たとえば、 遅い表示と速い表示の例をご覧ください。



最新のハイエンドデバイスでは、ディスプレイは特別なグラフィックプロセッサ（GPU）に接続されています。 GPUは、たとえば2Dレイヤーを配置したり、3D仮想シーンをレンダリングしたりすることにより、表示用のピクセルの配列を作成します。 GPUは、GPUハードウェア、アプリケーションおよびプラットフォームコードとの相互作用、および場合によってはディスプレイとの同期ロジックに依存する速度でフレームを生成します。



関連する問題は、アプリケーションコードが非常に遅く、GPUにそれを十分に活用するのに十分な速度で命令を送信しない場合に発生します。 これにより、アプリケーションから頻繁に指示があった場合よりも、GPUが独自のフレームを低速で作成する可能性があります。 これは、1秒あたり60フレーム未満を表示する2Dアプリケーションで見られるラグの一般的な原因です。



遅れ

「ジャンク」などのラグは言葉で説明するのは困難ですが、簡単に認識できます。 ジャンクフリーアプリの設計の記事でNathan Gitterは、それらを「予期しないまたは気を散らす視覚的なクラッシュ」と定義しています。

オーバーレイループ

断続的なアクティビティに起因する遅延があるパイプラインの少なくとも3つの部分、つまり入力スキャン、GPUレンダリングサイクル、および表示更新サイクルについて説明しました。 基本的にすべての遅延が加算されるような方法で結合できることに注意することが重要です。





数サイクル待機しています。 仮想遅延カスケードは、連続したハードウェアサイクルの待機が遅延を累積する方法を示しています。 縦の破線は、コンベヤーが予想するサイクルを示しています。



パイプラインの次のステップに進むには、次のサイクルまで待つ必要があります。 また、ループが互いに整列していない場合があります。 一貫性のないサイクルと好ましくない初期入力時間は、10ミリ秒の追加の遅延を引き起こす可能性があります。 これは、上記の遅延バジェットに比べてかなりの量です。

ランタイムのオーバーヘッド

ソフトウェア側では、ランタイム遅延はオペレーティングシステムやアプリケーションに直接関係しない他のコードに固有のものです。 ガベージコレクションとスケジューリングという2つの重要な例を検討してください。



まず、ガベージコレクション（GC）があります。 GCは、世界で最も広く使用されている2つのプラットフォーム（web（JavaScript）とAndroid（Java））で重要です。



場合によっては、ガベージコレクションは、特に低入力遅延の要件に関して、大きな遅延を引き起こす可能性があります。 JavaScriptまたはJava環境では、約10ミリ秒のガベージコレクションの遅延は驚くことではありません。 しかし、それは完全にタッチスクリーン上のオブジェクトをドラッグするための予算全体です！



ガベージコレクションは、1フレームだけ遅延する可能性があります。 しかし、フレーム損失による遅延の場合のように、そのようなジャークはユーザーを困らせます。



GCの遅延を減らす方法があります。 これには、可能な限り多くのGC作業をメインスレッドの外に移動することや、GC作業を最適化するための小さな個別の一時停止が含まれます。 たとえば、できるだけ多くのガベージコレクション操作をメインストリームから移動するV8の取り組みと、GCの遅延を1ミリ秒よりも大幅に短縮するGoの取り組みを参照してください。



GCの利便性を部分的に犠牲にするが、より予測可能なパフォーマンスを持つプログラミング言語を使用する別のオプションがあります。 Swiftのような言語は、 自動参照カウントを使用して任意のガベージコレクションを回避します 。



オーバーヘッドの別の潜在的な原因は、オペレーティングシステムのシェディングです。 私たちのアプリケーション（およびOSにおけるその依存関係）は、必ずしも常に動作するとは限りません。 他のプログラムは、非常に短い時間ではありますが、強制的に中断されている間、打ち上げをスケジュールすることができます。 各プログラムには時間がかかり、プロセッサコアの数は制限されています。



ディスパッチの問題にはCPU使用率が関係しています。 アプリケーションがパフォーマンスの目標を満たしているが、コンピューティングリソースのほぼ100％を必要とする場合、これはユーザーを困らせる可能性があります。 バッテリーの消費量が増加し、デバイスが熱くなり、ファンでノイズが発生し始める可能性があります。 言い換えれば、ceteris paribus、低いCPU使用率はユーザーにとってより良いことです。

故意の遅延

モバイルインターフェイスの遅延の典型的な原因は、OS自体とアプリケーションの設計です。 実際の期待によってのみ達成できる重要な相互作用がいくつかあります。



AndroidとiOSは、「長押し」を頻繁に使用してコンテキストメニューにアクセスします。 ユーザーは、コマンドを実行するために数百ミリ秒待機する必要があります。



あいまいさを排除するために、これに関連する遅延があります。 たとえば、モバイルSafariでは、ユーザーがリンクをクリックしてからブラウザが新しいページの読み込みを開始するまでに、350ミリ秒のデフォルトの遅延があります。 これは、リンクのクリックとダブルタップ（ズーム）の違いを判断するためです。 この特定の遅延については、詳細を参照してください。 また、アプリケーション開発者がこの問題を回避できるようにする最新の変更に関する情報もあります。

敵対的なエージェント

インターネット上のユーザーの一般的な遅延の原因は、悪意のあるアクティビティです。たとえば、ユーザーのアクションを追跡し、侵入型広告をダウンロードするアクティビティトラッカーです。





Washington Post Webサイトの500語の記事には、約100のHTTPリクエストが必要で、ロードに約4400ミリ秒かかります。 トラッカーと広告には多くのクエリが必要です。 それらの小さな部分が示されています。



肥満ウェブには多くの素晴らしい記事があります： The Bullshit Web 、 「The Crisis of Obesity Sites」、 Web bloatなどを参照してください。



多くのサイトでの遅延の最大の原因は、ユーザーの意欲に反するすべてのナンセンスのロードであることを単に強調します。

アプリケーションコード

最後に言及した遅延の原因はおそらく最も明白です。これはアプリケーション自体です。 アプリケーションが入力の処理またはアクションの実行に多くのプロセッサ時間を費やす場合、処理は遅くなります。

すべてをまとめる

合計遅延が構成されている例を見てみましょう。





入力から画面表示までのエンドツーエンドの遅延の仮想的な例。 垂直の破線は、コンベアが予期するサイクルを示しています。



上記の例は架空のものですが、示唆的なものです。 遅延を追加するレイヤーの数を示しているため、フルフレームレートで実行しても、アプリケーションは非常に遅くなる可能性があります。

高速ソフトウェアへ

ディープテクノロジースタックは、ユーザーの操作で最新のコンピューターインターフェイスに応答する役割を果たします。 キーボードの単純なキーストロークと、入力テキストボックス内の対応する文字の外観でさえ、キーボードのスキャンから、OSとフレームワークの処理レイヤー、ビデオカードのレンダリング、ディスプレイのリフレッシュレートまで、長い複雑な手順を経る操作です。



このような複雑さには理由がありますが、生産的に仕事をしようとしているコンピューターユーザーは、砂時計のアイコンを見て、自分のデバイスが単にそれに追いついていないように感じることを頻繁に待ち続けています。



高速なソフトウェアは、ユーザーに力を与え、生産性を向上させると考えています。今日のソフトウェアは、ユーザーを失敗させ、速度が遅くなることがよくあります。状況を改善したいと考えています。この資料が、ご自身のソフトウェアで作業する際に役立つことを願っています。

文学

1.遠藤、王、陳、セルツァー。「遅れてインタラクティブシステムの有効性の評価»、オペレーティングシステムの設計と実装上の第2回USENIXシンポジウム、1996年



2ン、アネット、ディーツ、グプタ、ビショフ。「時間がない中：知覚遅延研究スタイラス»との相互作用、コンピューティングシステムにおける人的要因に関する第32回ACM会議議事録、2014年



3呉Lepinsk、Vigdor、サンダース、ディーツ。「低遅延の直接タッチ入力を備えたデバイスの開発」、第25回ユーザーインターフェイスソフトウェアおよび技術に関するACMシンポジウムの議事録、2012年



。4. Deber、Jota、Forlays、Wigdor。「どんな速度で十分ですか？直接および間接タッチインターフェースの遅延とその改善に対するユーザーの認識」、第33回コンピューティングシステムのヒューマンファクターに関するACM年次会議の議事録、2015年



。「どのレベルまで行けばいいですか？描画の遅延の認知を理解する»、グラフィックスインタフェース2014の議事録、2014年



6 Forchの、フランケ、ラウフ、クレムス。「100ミリ秒で十分ですか？」マウスとの相互作用の遅延の閾値知覚の特性評価”、工学心理学および認知人間工学：認知とデザイン、



2017。7. Dabrowski、Manson。「コンピューターシステムに最適な応答時間を見つける40年」、コンピューターとの対話、2011年



。「ユーザーとそのマウスクリックで無意識生理検索の遅延効果の影響»、第38回国際、情報パーツ検索における研究及び開発に関するACM SIGIR会議、2015。