Pourquoi la saisie ne ralentit pas, même lorsque le document s’allonge
Pour une note courte, n’importe quel éditeur est rapide. La différence apparaît lorsque le document s’allonge, selon que le coût d’une seule touche dépend de la taille de la modification ou de celle du document.
Une note courte est rapide à écrire avec n’importe quel éditeur. La différence apparaît lorsque le document s’allonge.
Si, à chaque pression sur une touche, l’éditeur relit tout le document et réorganise l’écran, la saisie ralentit à mesure que le document s’allonge. C’est pourquoi un éditeur qui convenait parfaitement pour une note de dix lignes devient pénible à utiliser avec un document de conception de deux mille lignes.
mote n’a pas considéré ce problème comme un souci de performance à corriger plus tard. Dès le départ, il en a fait un principe de conception à respecter.
Lors d’une modification, seules les parties modifiées sont relues et mises en page. L’ensemble du document n’est relu qu’à l’ouverture du fichier.
Seules les parties modifiées sont relues
En Markdown, une ligne précédente peut modifier le sens des lignes suivantes. Si un bloc de code est ouvert en haut du document, tout le contenu qui suit peut devenir du code, et une même phrase est interprétée différemment selon qu’elle se trouve dans une liste ou dans une citation.
C’est pourquoi mote mémorise les « points sûrs » où l’influence de ce qui précède prend fin avec certitude. Lorsqu’une modification survient, il commence la lecture au point sûr le plus proche et s’arrête dès que le contenu se stabilise de nouveau.
Les blocs qui suivent ne sont pas relus. Si des lignes ont été ajoutées ou supprimées, seule leur position est décalée. Ainsi, le coût dépend de la zone réellement modifiée, et non de l’ensemble du document.
L’analyseur suit l’algorithme ligne par ligne de CommonMark et réussit les 652 tests de la spécification. Mais le traitement incrémental peut facilement produire des erreurs discrètes. C’est pourquoi 3 600 modifications aléatoires sont appliquées à des documents aléatoires, puis le résultat est chaque fois comparé à celui obtenu en relisant l’intégralité du document.
Ce test a également permis de découvrir un véritable bug. Il se produisait lorsque le point sûr coïncidait exactement avec la ligne modifiée.
Les principes de performance sont garantis par des tests
L’objectif est un temps p95 de 4 ms entre la pression sur une touche et la fin du traitement par le cœur. Tout dépassement de ce délai est traité comme un bug, et non comme une simple piste d’amélioration.
Cette règle n’est pas seulement consignée dans un document. Des tests automatisés vérifient que la nouvelle analyse complète n’est utilisée qu’à l’ouverture d’un fichier. Ils empêchent également les minuteurs ou les traitements d’image de se répéter lorsque l’application est inactive.
Les performances ne sont pas non plus évaluées à l’œil nu. Le banc de test saisit des caractères dans l’interface réelle et mesure la distribution des temps de traitement. Il examine le p95 plutôt que la moyenne ou la médiane. En effet, ce sont les longs délais occasionnels, plus que la vitesse habituelle, qui donnent à l’utilisateur une impression de lenteur.
Les mesures utilisent toujours le même document fixe.
doc100k.md utilisé par le banc de test. La barre d’état indique 96 513 caractères et un temps de lecture de 103 minutes.L’écran aussi ne change que dans la mesure nécessaire
Rendre uniquement l’analyseur incrémental ne suffisait pas.
La coloration syntaxique des blocs de code retraitait tous les blocs à chaque modification. C’était la dernière opération dont la lenteur augmentait avec la longueur du document, indépendamment de la taille de la modification.
Désormais, la coloration syntaxique des blocs non modifiés est réutilisée telle quelle. Les blocs situés après la modification sont seulement déplacés en fonction du nombre de lignes ajoutées ou supprimées.
Les blocs situés hors de l’écran ne sont pas mis en page. En effet, pour préserver la vitesse dans les longs documents, il faut réduire à la fois la zone relue et la zone redessinée.
Il existe aussi des exceptions
Dans certains cas, il faut retraiter l’ensemble du document.
C’est le cas lors de l’ouverture d’un fichier ou lorsque le format des sauts de ligne change. La modification de la définition d’une référence de lien pouvant affecter n’importe quel lien du document, la zone de rafraîchissement de l’écran est alors étendue à l’ensemble du document.
Même lorsque le cœur est rapide, l’affichage doit attendre l’image suivante. Sur un écran à 60 Hz, l’intervalle entre les images constitue lui-même une limite. C’est pourquoi le temps de traitement du cœur et le délai avant l’apparition effective à l’écran sont mesurés séparément et ne sont pas placés sur le même axe. Voilà pourquoi les deux lignes de la couverture sont différentes.
Un éditeur rapide n’est pas un éditeur qui fait tout rapidement.
C’est un éditeur qui ne fait pas ce qui n’a pas besoin d’être fait.