Ce n’était pas Markdown qui alourdissait l’application, mais le moteur web

J’avais laissé un éditeur Markdown ouvert sur mon ordinateur portable. Je ne saisissais rien, mais les ventilateurs ont commencé à tourner.

Au début, j’ai pensé que c’était à cause de Markdown. Je me suis dit que c’était lent parce que le document était continuellement redessiné.

Était-ce vraiment le cas ?

J’ai effectué la comparaison dans les mêmes conditions

J’ai utilisé la même taille d’écran, le même mode de rendu et le même document. J’ai ouvert un document de 7,5 Ko et 113 lignes, puis je n’ai rien fait pendant 25 secondes. Pour la saisie aussi, j’ai tapé les mêmes caractères à la même vitesse.

Au repos, apostrophe, qui génère l’aperçu avec un moteur web, utilisait 34,6 % du processeur et 378 Mo de mémoire. Il exécutait cinq processus.

Le prototype, qui affichait le même document en ligne sans moteur web, utilisait 0,7 % du processeur et 64 Mo de mémoire. Il n’exécutait qu’un seul processus.

Tous deux affichaient du Markdown, mais les résultats étaient très différents.

Dès que j’ai désactivé uniquement l’aperçu dans apostrophe, l’utilisation du processeur est tombée à 7,0 % et celle de la mémoire à 133 Mo. L’application et la boîte à outils étaient restées les mêmes. Seule la manière de générer l’aperçu avait changé.

J’ai également mesuré un éditeur de texte qui n’affichait aucun Markdown. Il utilisait 2,2 % du processeur et 79 Mo de mémoire.

Le prototype qui affichait du Markdown était même plus léger.

C’est alors devenu évident. Le problème ne venait pas de Markdown.

Il travaillait 60 fois par seconde même quand personne ne faisait rien

La cause se trouvait dans le code qui synchronisait le défilement de l’aperçu avec celui du corps du texte.

Ce code ne s’exécutait pas uniquement lors du défilement. Toutes les 16 ms, un minuteur se réveillait et exécutait du JavaScript dans le processus WebKit. À la réception de la réponse, il programmait de nouveau le minuteur.

Même lorsque personne ne touchait à la fenêtre, il travaillait ainsi environ 60 fois par seconde.

Lorsqu’on utilise un moteur web, la zone d’édition du document et celle qui génère l’aperçu deviennent deux mondes distincts. Le moyen le plus simple de synchroniser leurs états consiste à les vérifier continuellement. Si l’on ne mesure pas séparément l’utilisation du processeur au repos, ce coût passe facilement inaperçu.

Pendant la saisie, l’écart était encore plus grand. apostrophe utilisait 180 % du processeur, contre 41 % pour le prototype.

D’un côté, chaque frappe faisait des allers-retours jusqu’au processus du navigateur. De l’autre, seules les lignes modifiées étaient de nouveau balisées.

J’ai transformé les résultats des mesures en principes de conception

Le prototype ne comportait aucune optimisation particulière.

Les styles étaient appliqués au texte à l’aide de balises. Plusieurs modifications étaient regroupées dans une unique tâche inactive ponctuelle, qui disparaissait d’elle-même. La nouvelle application des balises était limitée aux lignes modifiées. Un seul processus était utilisé.

Il ne s’agissait pas d’ajouter quelque chose, mais de ne pas conserver ce qui était inutile.

J’ai ensuite adopté deux principes de conception.

Premièrement, ne pas inclure de moteur web dans les dépendances.

Deuxièmement, si le document ne change pas et qu’il n’y a aucune animation, ne programmer aucune image, aucun minuteur et aucun tick.

Ces principes sont difficiles à appliquer après coup. Un moteur web n’est pas une simple bibliothèque : il modifie la structure de l’application. Une fois intégré, le retirer revient à reconstruire l’application. Sans règle, les minuteurs se multiplient eux aussi, un pour chaque fonctionnalité.

En contrepartie, il a fallu renoncer à la facilité. Il n’était pas possible de détecter les modifications de fichiers par interrogation périodique, ni de confier les formules à une vue web. Il fallait créer directement les mises en page nécessaires.

Pour éviter que ces principes ne s’estompent, j’effectue de nouvelles mesures sur un appareil réel à chaque version.

Il faut aussi prendre quelques précautions lors de l’interprétation des chiffres

L’expérience a été menée avec un rendu logiciel. L’utilisation du processeur est donc plus élevée que dans un environnement équipé d’un véritable GPU. Il faut par conséquent regarder les proportions plutôt que les valeurs absolues.

Les 0,7 % d’utilisation du processeur au repos par le prototype correspondaient eux aussi principalement au clignotement du curseur. Lorsque je désactivais ce clignotement, il était difficile de distinguer la valeur obtenue de zéro.

Cela ne signifie pas que toutes les applications fondées sur un moteur web rencontrent le même problème. Ces résultats se limitent à apostrophe. Certains moteurs, comme ceux de la famille Chromium, réduisent le travail effectué au repos.

Le prototype ne comportait pas non plus beaucoup de fonctionnalités. Il n’avait ni tableaux, ni formules, ni exportation, ni fonction de recherche. La comparaison ne peut porter que sur le coût du rendu.

Une chose était néanmoins claire.

Ce n’était pas Markdown qui générait ce coût. C’étaient le moteur de rendu et la boucle qui ne s’arrêtait jamais.

Lorsqu’on identifie précisément la cause, la légèreté ne devient pas une nouvelle fonctionnalité, mais une soustraction.