Pourquoi nous publions des chiffres au lieu de simplement dire que c’est léger
Dire que c’est léger n’offre rien à vérifier. mote a fixé huit chiffres pour parler de lui-même et publie avec eux la méthode de mesure, les conditions et les données brutes.
Les éditeurs Markdown sont souvent présentés ainsi.
Rapide. Léger. Fluide.
Mais si les chiffres ne sont pas accompagnés de leurs conditions, ils ne valent pas mieux que des adjectifs. Quand le CPU au repos a-t-il été mesuré, et pendant combien de temps ? Entre quels points le temps de démarrage a-t-il été calculé ? Car des chiffres obtenus dans des conditions différentes ne peuvent pas être comparés.
C’est pourquoi nous avons fixé à huit le nombre d’indicateurs de performance publiés par mote. Pour chaque indicateur, nous avons consigné la méthode et les conditions de mesure, les éléments exclus, les règles de comparaison, les points d’attention et le budget. Nous avons également associé un script de mesure à chacun d’eux.
La documentation, les résultats et le code utilisent tous les mêmes noms. Cela permet de retrouver immédiatement l’origine de chaque chiffre.
Les chiffres doivent être accompagnés de leurs conditions
mote respecte quatre principes.
Pour chaque mesure, nous enregistrons ensemble la valeur, l’unité, la statistique, le nombre d’échantillons et les échantillons bruts. Tout résultat dépourvu d’unité est rejeté à l’étape de vérification.
Nous n’indiquons pas les valeurs que nous n’avons pas mesurées. Si une mesure est impossible, nous la laissons vide en précisant pourquoi. Nous ne la remplaçons pas par une estimation.
Nous n’effectuons les comparaisons que sur la même machine et au cours de la même session. Nous ne plaçons pas côte à côte des chiffres obtenus un autre jour ou sur un autre appareil.
Nous publions aussi les conditions de mesure avec les chiffres. Nous indiquons notamment toujours la fréquence de rafraîchissement et le gouverneur du CPU. Si ces conditions diffèrent, il est impossible de comparer correctement la latence et le temps de démarrage.
Nous n’avons pas inventé de nouvelles méthodes de mesure.
Pour la latence entre la frappe d’une touche et la modification de l’écran, nous avons repris exactement la méthode utilisée par Typometer de Pavel Fatin. Une touche est saisie depuis l’extérieur de l’application, puis nous attendons qu’un pixel change. Comme VS Code, nous avons décomposé le temps de démarrage en plusieurs étapes et distingué le démarrage à froid du démarrage à chaud.
Le principe selon lequel la latence doit être mesurée de bout en bout, et non à l’intérieur du framework, vient d’un article de Dan Luu.
Nous avons effectué nous-mêmes les comparaisons dans les mêmes conditions
Nous n’avons pas repris ailleurs les chiffres de performance des applications concurrentes. Nous les avons mesurés nous-mêmes sur le même ordinateur portable.
Nous avons ouvert le même document de 100 KB et exécuté chaque application sept fois avec le même script. Toutes utilisaient l’écran d’édition en ligne, et la position du pointeur était identique.
Voici l’utilisation totale de la mémoire par les processus.
- mote : 78 MB
- Typora : 453 MB
- Obsidian : 361 MB
- MarkText : 416 MB
Pendant la saisie, l’utilisation du CPU, rapportée à un cœur, était respectivement de 10,9 %, 103 %, 152 % et 136 %. Le nombre de processus était respectivement de 1, 8, 7 et 6.
mote utilisait entre 4,6 et 5,8 fois moins de mémoire. Pendant la saisie, il utilisait entre 9,4 et 14 fois moins de CPU.
La mémoire a été calculée en PSS, et non en RSS. Le RSS peut compter plusieurs fois la mémoire partagée entre plusieurs processus. Le PSS répartit la mémoire partagée entre les processus pour effectuer le calcul. C’est également la méthode utilisée par le moniteur système.
Nous avons aussi conservé tels quels les chiffres qui nous étaient défavorables
Lorsque les applications étaient simplement laissées ouvertes, l’utilisation du CPU était de 0,0 % pour mote, 0,1 % pour Typora, 0,8 % pour Obsidian et 0,6 % pour MarkText.
Typora n’utilisait presque pas de CPU au repos non plus. Nous ne pouvons donc pas présenter le fait que « rien ne se passe lorsqu’on le laisse ouvert » comme un avantage sur Typora.
Le shell web utilisait 3,6 %, ce qui était même moins bon que Typora.
Il reste important de supprimer les minuteurs répétitifs internes à l’application. Mais un principe à respecter et un avantage concurrentiel sont deux choses différentes.
Nous n’avons pas comparé le nombre d’images au repos avec celui des applications concurrentes. L’objectif de mote est de produire 0 image en 10 secondes, mais les autres applications ne disposent pas d’un compteur d’images permettant de le vérifier de la même manière.
Nous avons donc laissé vides les cases des applications concurrentes. Une case vide ne signifie pas zéro.
Si une comparaison est impossible, nous ne comparons pas
Nous vérifions aussi que le fichier d’origine reste parfaitement intact lorsqu’il est ouvert puis enregistré sans modification.
mote vérifie les 652 exemples de CommonMark. Nous ouvrons également tous les documents du dépôt, les enregistrons de nouveau, puis vérifions qu’ils sont identiques octet par octet. À la moindre différence, nous considérons qu’il ne s’agit pas d’un problème de performance, mais d’un bug entraînant une perte de données.
Nous n’avons pas indiqué les résultats des applications concurrentes. Il était difficile d’automatiser leur processus d’enregistrement dans les mêmes conditions.
Nous vérifions aussi l’état de la machine avant chaque mesure. Nous ne commençons pas les mesures si une compilation est en cours. Nous ne bloquons le navigateur que lorsqu’il utilise effectivement beaucoup de CPU. La charge moyenne, le taux d’inactivité du CPU, les critères de décision et les valeurs relevées au moment de la mesure sont tous conservés dans les résultats.
Ces règles sont nées après un échec.
Nous avions mesuré le temps de démarrage en laissant ouvert un navigateur qui utilisait beaucoup de CPU, ce qui donnait l’impression que les performances s’étaient dégradées. En mesurant alternativement le commit précédent et le commit actuel sous la même charge, nous avons constaté que la cause n’était pas une régression du code, mais la charge de la machine.
Depuis, nous ne jugeons plus le temps de démarrage sur la seule base d’une valeur absolue.
Le dépassement du budget empêche toute fusion
Le budget de performance n’est pas seulement un objectif inscrit dans la documentation. C’est un critère à respecter pour que le build soit validé.
Les critères sont répartis entre hard et report.
hard désigne les éléments dont les valeurs sont fixées dans un document de décision. Le contrôle échoue dès qu’un seul d’entre eux dépasse le seuil. Il n’existe aucune procédure distincte d’approbation des exceptions.
report désigne les éléments pour lesquels les données sont encore insuffisantes ou qui sont fortement influencés par les limites de la plateforme. Leurs valeurs sont enregistrées, mais elles ne bloquent pas le build.
Si l’on bloque le build sur la base de chiffres insuffisamment étayés, les gens finissent par éviter les mesures elles-mêmes. C’est pourquoi nous n’utilisons comme critères de validation que les seuils dont nous sommes certains.
Les scripts de mesure, les fichiers CSV d’origine et les résultats JSON sont conservés ensemble dans le dépôt. En exécutant les mêmes scripts dans les mêmes conditions, il est possible de recréer le tableau. Nous préparons également la publication des outils de mesure et des documents de test dans un dépôt public de benchmarks.
Ne retenir que les bons chiffres, ce n’est pas être transparent.
Montrer ensemble ce qui a été mesuré et comment, dans quelles conditions, mais aussi ce qui n’a pas pu être mesuré : voilà comment mote publie ses chiffres.