Du traducteur: le problème des logiciels lents est devenu l'un des principaux sujets de discussion sur Habré et Hacker News ces dernières semaines. Par exemple, voir l'article de Nikita Prokopov «My Disappointment in Software» et 2432 commentaires à ce sujet.
Nous passons beaucoup de temps à l'ordinateur. Nous attendons chaque fois que vous lancez des applications et chargez des pages Web. Partout, il y a des icônes de spinner ou de sablier. Le fer devient plus puissant, mais le logiciel semble toujours lent. Pourquoi
Si vous utilisez un ordinateur pour effectuer des tâches importantes, vous méritez un logiciel rapide. Trop souvent, les logiciels modernes ne répondent pas à ces exigences. Dans
le laboratoire de recherche Ink & Switch, nous avons étudié les raisons de cette situation, le logiciel s'est finalement amélioré. Cet article a publié les résultats de notre étude.
Table des matières
Où est exactement la lenteur
Qu'est-ce que les utilisateurs perçoivent comme un programme «lent»? Parfois, les logiciels nous ennuient tous avec des retards et des retards. Mais pour mieux comprendre ces problèmes, les sensations intuitives doivent être complétées par des études académiques qui répondent strictement à cette question.
La vitesse perçue est étroitement liée au concept de latence. Une comparaison de la recherche scientifique sur «ce qui semble lent» avec la mesure du retard réel dans ces applications montre clairement à quel point tout est mauvais.
Le retard n'est pas la bande passante
Lorsque nous discutons des performances des logiciels, nous entendons souvent parler de bande passante. Par exemple, «ce serveur Web peut exécuter 10 000 requêtes par seconde». Mais ce n'est pas ainsi que les utilisateurs perçoivent les choses. Ils se soucient du temps que prend leur demande Web particulière ou du temps nécessaire pour ouvrir un document, ou de la rapidité avec laquelle l'application répond à un clic de souris. Ces interactions sont associées à la latence. Le délai est une mesure critique que nous étudierons dans cet article.
Perception des utilisateurs
Pour plus d'informations sur l'importance de la latence dans les systèmes interactifs, voir ici .
D'autres facteurs influencent le sentiment de vitesse du logiciel. Par exemple, la fréquence d'images et les commentaires lors de longues tâches. Mais nous pensons que la latence est une mesure fondamentale, et avec une latence très faible, tout logiciel se sentira extrêmement rapide.Interfaces tactiles
Tout d'abord, considérez la sensibilité humaine aux retards de l'écran tactile.
Les chercheurs vérifient cela avec des tests qui déterminent exactement le délai que les utilisateurs perçoivent. Tout d'abord, les sujets se voient proposer une interface qui a (disons) un retard de 1 ms, puis (disons) 70 ms, et sont invités à effectuer des opérations comme appuyer sur un bouton. Si l'interface de 70 ms affiche systématiquement des résultats moins bons que l'interface de 1 ms, alors 70 ms est appelé la «différence notable».
Différence minimale perceptible
Pour plus de détails sur la différence minimale notable de retard et les installations expérimentales associées, voir, par exemple, ce travail .La différence minimale notable est le budget, après quoi une opération spécifique commencera à se sentir lente pour l'utilisateur.
Par exemple, lorsqu'ils font glisser des éléments sur l'écran, les utilisateurs perçoivent des retards de seulement ~ 2 ms. Le délai le moins visible dépend de l'utilisateur et de l'action en cours, mais il est toujours très faible.
Perception du glisser-déposer
Rapport de perception 2-16 ms lors d'un glissement avec un stylet .
2-11 ms lorsque vous faites glisser avec un doigt .
Une moyenne de 11 ms lorsque vous faites glisser avec un doigt .Des résultats similaires ont été obtenus lors du dessin avec un stylet sur une tablette. Ici, les chercheurs ont suggéré aux utilisateurs de remarquer un délai de 20 à 80 ms. Dans nos propres tests non officiels, un retard d'environ 80 ms est considéré comme très perceptible, et il faut quelque chose de beaucoup plus proche de 20 ms pour que le stylet apparaisse réactif pendant l'écriture manuscrite.
Perception du retard du stylet
Rapport sur la perception d'un retard de 10−70 ms lors de l'écriture avec un stylet .
21–82 ms pour diverses actions avec le stylet .La différence entre une latence d'écriture faible et élevée est évidente lorsque l'on compare:
Gauche: iPad Pro et application Notes avec une latence de bout en bout d'environ 15 ms. À droite: application Samsung S3 et OneNote avec un retard d'environ 70 ms. La vidéo est 16 fois plus lente.Une autre opération typique sur les appareils tactiles consiste à cliquer sur des boutons ou des liens. Ici, les tests ont déterminé que les utilisateurs remarquent un retard autour du tour de 70 ms (bien qu'il soit probablement plus faible pour certains utilisateurs individuels).
Perception du retard d'écran
Cette étude a révélé un retard moyen minimum de 69 ms.Voici un exemple comparant deux délais différents:
Gauche: ouverture de l'onglet des paramètres sur l'iPhone 6s avec un retard d'environ 90 ms. Droite: commutation des paramètres sur le Samsung S3 avec un retard d'environ 330 ms. La vidéo est 16 fois plus lente.Comment les applications modernes atteignent-elles ces seuils? Si nous parlons de glisser-déposer, alors aucun système commercial n'est capable de correspondre constamment à un retard de plusieurs millisecondes pour satisfaire tous les consommateurs.
Performances de glisser-déposer
Comme nous le verrons ci-dessous, même les écrans et les équipements de saisie de données ne rentrent pas dans le budget de 10 ms, sans parler de plusieurs couches de logiciels.Ainsi, lorsque vous utilisez tous les systèmes d'exploitation actuels avec un écran tactile, au moins certains utilisateurs sentiront que l'objet est derrière votre doigt lors du glisser-déposer.
Lorsque vous dessinez avec un stylet, un petit nombre de systèmes approchent un niveau de retard suffisamment bas. Mais la plupart d'entre elles sont bien supérieures à ces valeurs, ce qui est attendu par les utilisateurs comme un retard important:
Vous trouverez ci-dessous les résultats des tests Ink & Switch sur le retard de dessin avec le stylet sur la tablette pour divers appareils. Les retards moyens, mesurés depuis le contact avec l'écran jusqu'au début du changement de couleur du pixel correspondant, sont arrondis à 5 ms près.
| Périphérique | Le programme | Retard (ms) |
|---|
| iPad Pro | Remarques | 20 |
| Goodnotes | 30 |
| Flutter | 35 |
| Surface pro | OneNote | 25 |
| Sketchpad | 30 |
| Toile | 60 |
| Pixelbook | Squid | 40 |
| Toile | 60 |
| Samsung s3 | Squid | 60 |
| Flutter | 65 |
| Toile | 75 |
| Liveboard | 80 |
Bien que nous ne disposions pas de données sur les retards sur tous les appareils, nous supposons qu'ils sont comparables aux retards de dessin du stylet observés ci-dessus.
Dessiner les retards par rapport aux retards de clic
Nous nous attendons à ce que ces retards soient comparables, car dans les deux cas, une saisie tactile est utilisée, c'est-à-dire que le cycle de rafraîchissement de l'écran est activé. Cependant, il existe certaines différences, il est donc peu probable que les valeurs soient exactement les mêmes.Puisqu'un délai d'environ 70 ms est perceptible ici, la plupart des systèmes sont capables de bien répondre aux clics. Mais il est également facile de trouver des applications qui fonctionnent bien moins bien que les capacités théoriques du système.
En général, les systèmes sensoriels doivent avoir des latences très faibles pour qu'ils se sentent réactifs. La plupart des appareils et applications ne sont pas en mesure de fournir ce niveau de performances et, par conséquent, ils se sentent tous, à des degrés divers, lents pour les utilisateurs.
Clavier
Il existe des preuves qu'une augmentation de la latence de frappe nuit à l'expérience utilisateur.
Effet du retard d'entrée
Dans cette étude, des retards aléatoires ont été ajoutés aux frappes, ce qui a réduit les performances d'entrée. Cependant, il n'a évalué qu'une seule gamme de retards. De plus, les auteurs de l'étude suggèrent que les compositeurs expérimentés peuvent s'adapter à une latence accrue.Cependant, nous ne connaissons pas d'études mesurant spécifiquement les retards d'entrée les moins visibles. Le retard dans la pression de l'écran tactile (notable à environ 70 ms) peut être un guide utile car il mesure également le temps entre un toucher discret d'un doigt et un rafraîchissement visuel de l'écran.
Vous trouverez ci-dessous quelques mesures informelles du délai de bout en bout entre le début d'une frappe et l'apparition d'un personnage sur diverses machines. Sources:
«Latence informatique: 1977−2017» , tests Ink & Switch.
| Ordinateur | Retard (ms) |
|---|
| Apple iie | 30 |
| Commodore Pet 4016 | 60 |
| iMac g4 OS 9 | 70 |
| Macbook Pro 2014 | 100 |
| Haswell-e 24Hz personnalisé | 140 |
| Samsung s3 | 150 |
| Powerspec g405 Linux | 170 |
| Symbolics 3620 | 300 |
Des mesures précises des effets de la latence du clavier seraient une grande expérience pour les chercheurs aventureux. Dans tous les cas, il semble probable que pour de nombreux utilisateurs, le seuil d'un délai tangible lors de la saisie à partir du clavier soit inférieur à 100 ms. Peut-être beaucoup plus bas.
Une souris
Le dernier type de périphériques d'entrée dans notre revue.
Une expérience a déterminé que les utilisateurs percevaient une latence de la souris allant de 34 à 137 ms avec une moyenne de 65 ms.
Différentes souris ont des valeurs de retard très différentes. Certains systèmes affichent des valeurs inférieures à 10 ms en combinant un équipement haute performance avec une programmation minutieuse de bas niveau (
cela décrit l'installation avec un retard d'environ 8 ms). De plus, vous pouvez aller au-delà de 100 ms sur une combinaison d'équipements et d'applications médiocres qui introduisent des retards ou tampons supplémentaires entre la souris et l'écran.
Les applications
Les retards au niveau de l'application mesurent le temps nécessaire pour effectuer des actions d'application spécifiques, telles que le chargement de pages Web. Un exemple d'un tel retard est le chargement de la page Web NYTimes, qui prend environ 3000 ms.
Quand les actions de l'application semblent-elles rapides? Il est difficile de le dire avec certitude, car leurs actions sont plus complexes et diverses que la simple saisie de données. Probablement, la réponse dépend également des attentes des utilisateurs (actuellement, les gens travaillent généralement avec des logiciels lents). Mais nous pouvons calculer le nombre approximatif.
Littérature de retard
Voir la revue de littérature sur l'effet du retard sur les utilisateurs de différentes applications. C'est un bon point de départ pour une immersion plus approfondie dans le sujet.L'une des valeurs de référence est une métrique typique de 70 ms comme délai le moins visible mentionné ci-dessus lorsque vous cliquez sur l'écran. Si vous constatez un délai entre le clic sur un lien et l'affichage d'un indicateur de clic, vous devriez remarquer un délai similaire entre le clic et l'ouverture d'une page Web.
Une autre référence est
le modèle de développeur
Google RAIL . Bien que les auteurs de ce modèle ne justifient en aucune façon leurs déclarations, le modèle prétend que la réponse dans un délai de 100 ms «semble instantanée» et le délai plus élevé «[rompt] le lien entre action et réaction».
Vous pouvez vérifier officieusement votre propre sensibilité dans le terminal. Prenez vos programmes de ligne de commande préférés et exécutez-les avec le paramètre 'time', qui mesure le temps d'exécution. Notez sûrement la différence entre les réponses pendant 15 ms (excellent!) Et 500 ms (évidemment lent).
En tant que dernier point de référence, nous prenons en compte qu'un temps de réaction humain typique à un stimulus visuel est d'
environ 220 ms .
Cette valeur est beaucoup plus grande qu'un retard notable, car la réaction comprend non seulement l'observation, mais aussi l'action subséquente.
Il est également nécessaire de prendre en compte les
conclusions de certains chercheurs selon lesquelles une personne est capable de percevoir une augmentation du retard à un niveau physiologique inconscient.
De vraies applications
Comment les applications réelles correspondent-elles à ces directives? Certains s'en sortent. Par exemple, de nombreux programmes en ligne de commande Unix s'exécutent plus rapidement que 100 ms.
Mais la plupart des applications Internet sont hors de portée. Une recherche Google en environ 1000 ms est beaucoup plus rapide que la plupart des applications Web, mais elle est encore sensiblement plus lente que moins de 100 ms sur la ligne de commande. Et il est facile de trouver des exemples de pages qui se chargent plus de 5000 ms même avec une bonne connexion.
Dans le cas des ordinateurs mobiles et de bureau, certaines applications affichent systématiquement un retard de moins de 100 ms, comme une calculatrice intégrée sur iOS. Mais il est facile de trouver des exemples d'applications qui dépassent de loin ce seuil, même si toutes les données sont disponibles (ou devraient l'être) localement. Prenons l'exemple de Slack.
La vidéo ci-dessous montre que la commutation entre deux canaux à faible volume dans la même zone de travail sur l'iPad Pro prend environ 220 ms, bien qu'il n'y ait pas besoin d'appels réseau, et l'iPad Pro est sans doute l'appareil mobile le plus performant au monde (la vidéo est ralentie de 8 fois ):
Il est difficile de tirer une conclusion générale pour tous les programmes dans un domaine aussi vaste que le retard d'action. Néanmoins, il semble évident que certaines applications effectuent des actions assez rapidement et semblent instantanées pour les utilisateurs (moins de 100 ms), mais de nombreuses applications ne le font pas.
D'où vient le ralentissement?
Ainsi, nous avons constaté que de nombreux programmes fonctionnent réellement lentement. Où va tout ce temps et que pouvons-nous optimiser? Considérez ce problème, en commençant par le premier composant de la chaîne: les périphériques d'entrée.
Périphérique d'entrée
La première étape du pipeline, qui convertit les données d'entrée physiques en mises à jour sur l'écran, est le traitement des données d'entrée: la conversion du contact avec l'écran tactile, le clavier ou la souris en un signal numérique pour le système d'exploitation. Nous regardons ici combien de temps cette étape prend.
Commençons par les claviers. Le tableau montre les retards mesurés entre le début d'une frappe et un signal sur un concentrateur USB, arrondis à 5 ms (
source ).
| Clavier | Retard (ms) |
|---|
| Pomme magique | 15 |
| Das 3 | 25 |
| Kinesis freestyle2 | 30 |
| Ergodox | 40 |
| Avantage Kinesis | 50 |
| Logitech MK360 | 60 |
Comme vous pouvez le voir, ces claviers prennent facilement des dizaines de millisecondes du budget à la toute première étape du pipeline de traitement. C'est à partir d'un budget total de 100 ms ou moins! Ce sujet est traité plus en détail dans l'article
«Imprimer avec plaisir» .
Les souris prennent également des dizaines de millisecondes sur le budget. Bien que les souris de jeu les plus performantes aient un retard de moins de 10 ms. Les données sur la réponse à la pression varient, ici aussi, les instances individuelles montrent un résultat inférieur à 10 ms (
exemple ).
Dans les appareils mobiles, il est plus difficile de mesurer la proportion du retard qui tombe sur les appareils d'entrée car ils sont étroitement intégrés aux autres composants matériels. Cependant, nous pouvons utiliser certains des modèles courants dans l'équipement des périphériques d'entrée pour évaluer leurs retards, ainsi que les périphériques autonomes.
Taux d'échantillonnage
Un modèle courant est le taux d'échantillonnage. Dans de nombreux périphériques d'entrée, l'équipement «scanne» ou «échantillonne» les entrées à intervalles périodiques. Par exemple, un écran tactile grand public classique fonctionne à une fréquence de 60 Hz, c'est-à-dire qu'il interroge les capteurs toutes les 17 ms environ. Cela signifie que dans le pire des cas, le retard du périphérique d'entrée sera d'au moins 17 ms, et en moyenne pas plus de 8 ms.
Toutes choses étant égales par ailleurs, un taux de balayage plus élevé réduira le délai d'entrée. Par exemple, les écrans tactiles et les stylets avancés d'Apple fonctionnent à des fréquences supérieures à 60 Hz (informations provenant des
archives de documentation d'Apple ).
| Périphérique | Écran tactile (Hz) | Stylet (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 |
L'interrogation USB est une source de retard similaire. Le protocole USB reçoit une entrée du clavier, donc le clavier doit attendre un sondage USB pour envoyer des informations sur les clics. L'interrogation USB à faible vitesse fonctionne à 125 Hz, introduisant l'inévitable ~ 8 ms max. et ~ 4 ms de retard moyen. Versions ultérieures de scan USB avec une fréquence de 1000 Hz ou plus, minimisant l'effet du retard.
Il existe de nombreuses autres sources potentielles de retard dans les périphériques d'entrée, par exemple, le rebond de contact (pour plus de détails, voir l'article
«Analyse de la matrice du clavier et rebond de contact» sur les effets logiciels et matériels du rebond).
Nous ne considérerons pas toutes ces nuances ici, mais nous insistons sur les principales: a) les périphériques d'entrée eux-mêmes peuvent entraîner un délai important avant que tout traitement dans le logiciel ne se produise; b) cela peut être dû à plusieurs raisons discrètes, et le temps de retard est additionné.
Écrans et GPU
Le matériel à l'autre extrémité du convoyeur est constitué d'écrans et de cartes vidéo.
Une source de retard ici est la fréquence d'images d'affichage. Étant donné que les affichages ne peuvent pas être redessinés en permanence, cela entraîne un retard inévitable similaire aux périphériques d'entrée d'interrogation décrits ci-dessus. Si l'écran est mis à jour (disons) toutes les 20 ms, il ajoute alors 20 ms de retard dans le pire des cas et 10 ms en moyenne.
Perception du mouvement
D'autres facteurs influencent notre perception des objets se déplaçant sur l'écran. Blur Busters est une excellente ressource à ce sujet. Par exemple, voir Artéfacts de mouvement LCD 101 .La plupart des écrans fonctionnent à 60 Hz, bien que les appareils professionnels et les écrans de jeu fonctionnent à 120 Hz, 144 Hz et 240 Hz. Ainsi, seule la fréquence d'images affichée ajoute généralement au retard une moyenne d'environ 8 ms, bien que dans les écrans avec la fréquence d'images la plus élevée, elle puisse être réduite à quelques millisecondes.
Une autre contribution au retard des affichages est le temps nécessaire pour changer physiquement la couleur des pixels après avoir reçu de nouvelles données. Cette durée varie de quelques millisecondes dans les écrans de jeu haut de gamme à des valeurs à deux chiffres sur des écrans LCD moins réactifs.
Afficher le temps de réponse
Ce paramètre est difficile à mesurer, mais certaines données illustratives sont disponibles sur le site Web de Notebook Check . Par exemple, consultez l'exemple des affichages lents et rapides .Sur les appareils haut de gamme modernes, l'écran est connecté à un processeur graphique spécial (GPU). Les GPU créent un tableau de pixels à afficher, par exemple, en organisant des couches 2D ou en rendant des scènes virtuelles 3D. Les GPU produisent des trames à une vitesse qui dépend du matériel GPU, de l'interaction avec le code de l'application et de la plate-forme, et parfois de la logique de synchronisation avec les écrans.Un problème connexe se produit lorsque le code d'application est très lent et n'envoie pas d'instructions au GPU assez rapidement pour en tirer pleinement parti. Cela peut conduire le GPU à créer des cadres uniques à une vitesse inférieure à celle s'il avait vraiment des instructions fréquentes de l'application. Il s'agit d'une source courante de retards que nous constatons dans les applications 2D affichant moins de 60 images par seconde.Lagi
Type Lagi « de Jank » est difficile de décrire avec des mots, mais ils sont facilement reconnaissables. Nathan Gitter, dans l'article Designing Jank-Free Apps , les définit comme des «plantages visuels inattendus ou distrayants».Superposition de boucle
Nous avons discuté d'au moins trois parties du pipeline où il y a un retard dû à une activité intermittente: le balayage d'entrée, les cycles de rendu GPU et les cycles de rafraîchissement de l'affichage. Il est important de noter qu'ils peuvent être combinés de manière à ce que pratiquement tous les retards s'additionnent: en
attente de plusieurs cycles. La cascade de retard hypothétique montre comment l'attente de cycles matériels consécutifs peut accumuler un retard. Les lignes verticales en pointillés indiquent les cycles auxquels le convoyeur doit s'attendre.Pour passer à l'étape suivante du pipeline, nous devons attendre le prochain cycle. Et les boucles peuvent ne pas être alignées les unes avec les autres. Des cycles incohérents et un temps d'entrée initial défavorable peuvent entraîner un retard supplémentaire de 10 millisecondes. C'est un montant important par rapport aux budgets de retard décrits ci-dessus.Frais généraux d'exécution
Du côté logiciel, les retards d'exécution sont inhérents aux systèmes d'exploitation et autres codes qui ne sont pas directement liés à l'application. Prenons deux exemples importants: la récupération de place et la planification.Vient d'abord la collecte des ordures (GC). GC est essentiel dans les deux plates-formes les plus utilisées au monde: le Web (JavaScript) et Android (Java).Dans certains cas, la collecte des ordures peut entraîner un retard important, en particulier en ce qui concerne les exigences pour un retard d'entrée faible. Pour les environnements JavaScript ou Java, les retards de récupération de place d'environ 10 ms ne sont pas surprenants. Mais c'est tout le budget pour faire glisser des objets sur l'écran tactile!La récupération de place peut retarder une seule image. Mais comme dans le cas des retards dus à la perte de trame, ces secousses agacent les utilisateurs.Il existe des moyens de réduire le retard du GC. Il s'agit notamment de déplacer autant de travail GC que possible en dehors du thread principal, et d'optimiser le GC pour seulement quelques pauses distinctes. Voir, par exemple, les efforts de V8 pour déplacer autant d'opérations de collecte de déchets que possible hors du courant dominant et les efforts de Go pour maximiser les décalages GC considérablement inférieurs à 1 ms.Il existe une autre option pour utiliser un langage de programmation qui sacrifie partiellement la commodité du GC, mais a des performances plus prévisibles. Des langages tels que Swift évitent la récupération arbitrairecomptage automatique des références .Une autre source potentielle de surcharge est la suppression du système d'exploitation. Notre application (et ses dépendances dans le système d'exploitation) ne fonctionne pas nécessairement en permanence. Le lancement d'autres programmes peut être programmé, tandis que le nôtre est suspendu de force, mais pour une très courte période. Chaque programme prend du temps et le nombre de cœurs de processeur est limité.Le problème de répartition est lié à l'utilisation du processeur. Si votre application atteint ses objectifs de performances, mais qu'elle nécessite près de 100% des ressources informatiques, cela risque de gêner les utilisateurs. La consommation de la batterie augmentera, l'appareil chauffera et peut commencer à faire du bruit avec un ventilateur. En d'autres termes, une faible utilisation du CPU ceteris paribus est meilleure pour l'utilisateur.Retard délibéré
Une source typique de retards dans les interfaces mobiles est la conception du système d'exploitation lui-même et des applications. Il existe certaines interactions importantes qui ne peuvent être accomplies que par une attente réelle.Android et iOS utilisent fortement la "pression longue" pour accéder au menu contextuel. Ils obligent l'utilisateur à attendre des centaines de millisecondes pour exécuter la commande.Il y a des retards associés à cela pour éliminer les ambiguïtés. Par exemple, dans Safari mobile, il y a un délai par défaut de 350 ms entre le moment où l'utilisateur clique sur le lien et le moment où le navigateur commence à charger une nouvelle page. Cela est nécessaire pour déterminer la différence entre cliquer sur un lien et appuyer deux fois (zoom). Pour ce délai spécifique, voir ici pour plus de détails.. Il existe également des informations sur les dernières modifications qui permettent aux développeurs d'applications de contourner ce problème.Agents hostiles
Une activité courante de retard pour les utilisateurs sur Internet est l'activité malveillante, par exemple, les trackers d'activité qui suivent les actions des utilisateurs et téléchargent des publicités intrusives.
Un article de 500 mots sur le site du Washington Post nécessite une centaine de requêtes HTTP et prend environ 4400 ms à charger. De nombreuses requêtes sont nécessaires pour les trackers et les publicités. Une petite partie d'entre eux est montrée.Il existe de nombreux articles merveilleux sur l'obésité du Web: voir The Bullshit Web , "The Crisis of Obesity Sites" , Web bloat et autres. Noussoulignons simplement que la plus grande source de retard sur de nombreux sites est le téléchargement de toutes sortes de bêtises contre la volonté des utilisateurs.Code d'application
La dernière source de retard que nous mentionnons est peut-être la plus évidente: c'est l'application elle-même. Si une application passe beaucoup de temps processeur à traiter les entrées ou à exécuter une action, cela sera lent.Tout mettre ensemble
Prenons l'exemple de la composition du retard total: Un
exemple hypothétique de retard de bout en bout entre l'entrée et l'affichage à l'écran. Les lignes verticales en pointillés indiquent les cycles auxquels le convoyeur doit s'attendre.L'exemple ci-dessus est hypothétique, mais indicatif. Il montre combien de couches ajoutent du retard, de sorte que l'application peut être assez lente, même si elle s'exécute à pleine fréquence d'images.Vers un logiciel rapide
Une pile technologique approfondie est chargée de répondre à une interface informatique moderne avec les actions de l'utilisateur. Même une simple frappe sur le clavier et l'apparition du caractère correspondant dans la zone de texte d'entrée est une opération qui passe par une longue séquence complexe d'étapes: de la numérisation du clavier, en passant par les couches de traitement du système d'exploitation et du cadre, en passant par le rendu de la carte vidéo et le taux de rafraîchissement de l'affichage.Il y a une raison à cette complexité, et pourtant nous sommes tristes que les utilisateurs d'ordinateurs qui essaient de travailler de manière productive restent souvent en attente, en regardant l'icône du sablier et en sentant que leurs appareils ne peuvent tout simplement pas les suivre.Nous pensons qu'un logiciel rapide donne plus de pouvoir aux utilisateurs et les rend plus productifs. Nous savons que les logiciels actuels échouent souvent aux utilisateurs, étant lents, et nous voulons améliorer la situation. Nous espérons que ce matériel vous sera utile lorsque vous travaillerez sur votre propre logiciel.Littérature
1. Endo, Wang, Chen, Seltzer. «Retarder l'efficacité d'un système interactif» , Actes du 2e symposium USENIX sur la conception et la mise en œuvre des systèmes d'exploitation , 1996.2. Ng, Annette, Ditz, Gupta, Bischoff. « En un rien de temps: étude de retard de perception de l'interaction avec un stylet» , Actes de la 32e Conférence annuelle ACM sur les facteurs humains dans les systèmes informatiques , 2014.3. Ng Lepinsk, Vigdor, Sanders, Dietz. «Développement de dispositifs avec entrée tactile directe à faible latence» , Actes du 25e Symposium annuel ACM sur les logiciels et technologies d'interface utilisateur , 2012.4. Deber, Jota, Forlays, Wigdor.«Quelle vitesse est suffisante? Perception par l'utilisateur du retard et de son amélioration dans les interfaces tactiles directes et indirectes » , Actes de la 33e Conférence annuelle de l'ACM sur les facteurs humains dans les systèmes informatiques , 2015.5. Annette, Ng, Ditz, Bischof, Gupta. «À quel niveau faut-il aller? Understanding the Delay Perception of Drawing » , Proceedings of Graphics Interface 2014 , 2014.6. Forch, Franke, Rauch, Krems. "Est-ce que 100 ms suffisent?" Caractérisation de la perception seuil du retard dans l'interaction avec la souris » , Engineering Psychology and Cognitive Ergonomics: Cognition and Design , 2017.7. Dabrowski, Manson.«40 » ,
Interacting with Computers , 2011.
8. -, , , , .
« » ,
38th International ACM SIGIR Conference on Research and Development in Information Retrieval , 2015.