Des chiffres que nous pouvons vous aider à reproduire.

Environnement

Tous les chiffres de cette page proviennent d’une seule machine : l’ordinateur portable sur lequel l’application est développée, avec une configuration graphique intégrée ordinaire. La version Windows n’a pas encore été mesurée ici et la version macOS est en développement ; leurs lignes apparaîtront ici lorsqu’elles existeront.

Document de test : tools/perf/fixtures/doc100k.md (100 KB, 874 lignes) · 3 exécutions, médiane · pointeur laissé hors de la fenêtre · bus de session réel.

Images au repos

Affirmation : quand rien ne se passe, mori ne dessine rien. Le document est ouvert dans la vue Live, l’éditeur n’a pas le focus — le curseur ne clignote donc pas — et aucune entrée n’a lieu pendant 10 secondes (t = 5–15 s après le lancement). Nous comptons les instantanés de l’éditeur : chaque fois que GTK lui demande de se dessiner.

Lorsque le clignotement du curseur est activé — comportement par défaut quand la fenêtre a le focus — l’éditeur se redessine une fois par clignotement : seul le curseur change. Cela cesse dès que la fenêtre perd le focus. Ce clignotement est l’unique temporisateur répétitif autorisé dans l’application ; il n’en existe aucun autre au repos.

Latence de saisie

Affirmation : 18.2 ms de la touche au pixel, au 95e centile. Mesuré depuis l'extérieur du processus par tools/perf/index/e2e_latency.sh : une touche est injectée avec XTest et l'écran est interrogé jusqu'à ce que la ligne du curseur change. Document de 100 Ko, vue Live, 2560×1440 à 180 Hz. Sur 119 frappes : p50 14.1, p95 18.2, p99 19.1, max 20.4 ms.

Ce chiffre couvre tout ce qui se trouve entre la touche et le pixel : la boîte à outils, le compositeur et l'attente de l'image suivante. Cette attente tombe n'importe où entre zéro et un intervalle de rafraîchissement — à 180 Hz, au plus 5.6 ms et 2.8 en moyenne — c'est pourquoi ce chiffre ne se compare qu'à un autre éditeur mesuré au même taux de rafraîchissement. Le temps de réponse de l'écran lui-même n'est pas inclus ; nous ne l'avons pas mesuré.

Démarrage à froid

Affirmation : 387 ms du lancement à la fenêtre, avec un fichier de 100 Ko ouvert et rien en cache. À froid signifie un processus neuf et un cache de pages vidé : le binaire, les bibliothèques et le fichier viennent tous du disque. Avec le cache chaud — le cas de tous les jours — le même lancement prend 259 ms. L'horloge démarre à exec et s'arrête quand la fenêtre apparaît ; le premier rendu est la même horloge arrêtée au premier dessin du document.

Méthode : tools/perf/run-index.sh, à froid = processus neuf avec cache de pages vidé, fichier de 100 Ko ouvert au lancement, cinq passages. La mémoire est le PSS lu dans /proc une fois le document mis en page et l'application au repos, moins la même lecture avec un document vide — ce que le document nous coûte : 9.4 Mo sur 70 Mo. Le reste est le socle boîte à outils et GPU que paie toute application GTK4 sur cette machine ; il bouge avec le pilote, et c'est pourquoi nous publions notre part. Le binaire pèse 6.1 Mo. Le premier rendu est lu dans le compteur de trames de l'éditeur, que seule notre build dev possède — les trois autres affichent un tiret plutôt qu'une estimation.

Même machine, même document

Typora, Obsidian et MarkText, chacun ouvert sur le même document de 100 Ko dans sa vue d'édition en ligne (le WYSIWYG de Typora, la Live Preview d'Obsidian, MarkText), sur la machine ci-dessus, dans la même exécution que nos propres chiffres. La mémoire est le PSS de tout l'arbre de processus une fois le document mis en page et l'application au repos ; le CPU au repos est celui de l'arbre sur trente secondes, fenêtre au premier plan et sans saisie ; le CPU de frappe est celui de l'arbre pendant la saisie d'environ 700 caractères à un rythme humain, un toutes les 150 ms.

C'est au repos que les moteurs divergent d'abord : fenêtre ouverte et rien à faire, mori n'utilise aucun CPU mesurable et se réveille zéro fois par seconde, tandis que les trois éditeurs Electron restent à 1.1–1.6 % et 29–75 réveils. Ensuite la frappe : une fraction de cœur contre un tiers à deux tiers. Enfin la mémoire : un processus contre six à neuf, 70 Mo contre 346–457.

MarkText a tourné avec --no-sandbox (son bac à sable ne démarre pas sur ce noyau) ; Obsidian a tourné dans un répertoire de données séparé. Données brutes : tools/perf/results/2026-09-09-linux-myasus-180hz.json.

Reproduire les mesures

Le harnais et le fichier de résultats sont dans le dépôt ; un dépôt public avec le corpus et les données brutes est en préparation, sans date pour l'instant. tools/perf/run-index.sh exécute tous les indices ; tools/perf/check.sh valide le résultat au regard des budgets. Si vos chiffres s'écartent des nôtres de plus de 15 %, dites-le-nous ; nous publions l'écart.

Dernier passage : 2026-09-09, une seule exécution de tools/perf/run-index.sh sur le commit 183cc22 — tous les chiffres de cette page, les nôtres comme ceux des autres éditeurs, viennent de cette exécution. Refait à chaque version.