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. Les versions macOS et Windows sont 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, mote 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 : 9.7 ms entre la frappe et le pixel, au 95e centile. Frappe → traitement : p95 0.29 ms. Frappe → pixel, vsync comprise : p95 9.7 ms. Mesure interne par tools/perf/typing.sh, document de 100 KB, vue Live.

« Traitement » signifie que l’événement de saisie a mis à jour le document et invalidé les mises en page concernées ; « pixel » désigne la fin de l’instantané suivant, qui attend l’horloge d’image et est donc bornée inférieurement par la vsync (16.7 ms à 60 Hz). Sur 300 frappes, les deux distributions étaient p50 0.01 / p95 0.29 / max 0.48 ms et p50 2.6 / p95 9.7 / max 12.7 ms, mesurées le 2026-09-02 sur la version M3, un commit antérieur à l’exécution de contrôle ci-dessous ; l’exécution de frappe ne figure pas encore dans le répertoire des résultats, il faut donc la relancer avant de s’y fier. Le temps de réponse propre à l’écran n’est pas inclus ; nous ne l’avons pas mesuré.

Démarrage à froid

Affirmation : 211 ms entre le lancement et la fenêtre, avec un fichier de 100 KB ouvert. « À froid » signifie un nouveau processus, avec le fichier ouvert au lancement ; rien n’est préchauffé et le cache de pages est laissé tel quel. Le chronomètre démarre à exec et s’arrête lorsque la fenêtre est affichée ; la première image utilise le même chronomètre, arrêté au premier instantané du document par l’éditeur.

Méthode : tools/perf/gate.sh, à froid = nouveau processus, fichier de 100 KB ouvert au lancement. La PSS est lue dans /proc au bout de quinze secondes, une fois le document mis en page et l’application revenue au repos.

Même machine, même document

Typora, Obsidian et MarkText ont chacun ouvert le même document de 100 KB dans leur vue d’édition en ligne — WYSIWYG pour Typora, Live Preview pour Obsidian, vue standard pour MarkText — sur la machine ci-dessus, au moyen du même script. La mémoire correspond à la PSS de toute l’arborescence de processus douze secondes après le lancement ; le CPU au repos est celui de l’arborescence entre les secondes 5 et 10, fenêtre active et sans saisie ; le CPU de frappe est celui de l’arborescence pendant la saisie d’environ 150 caractères à raison d’un caractère toutes les 30 ms. Sept exécutions par éditeur, moyenne, après une exécution de préchauffage écartée.

Le CPU au repos de Typora est aussi faible que le nôtre — nous le précisons. Chromium ralentit lorsqu’il est réellement inactif : la colonne au repos distingue donc mote d’Obsidian et de MarkText, pas de Typora. C’est sur la mémoire et le coût de la frappe que les moteurs divergent : un processus contre six à huit, et un dixième du CPU par frappe. Les 78 MB indiqués ici dépassent les 69 MB ci-dessus parce qu’il s’agit de l’ensemble de l’arborescence de processus dans une autre session ; le socle GTK et Mesa varie d’une douzaine de mégaoctets entre les sessions.

MarkText a été exécuté avec --no-sandbox — son bac à sable ne démarre pas sur ce noyau ; Obsidian a été exécuté dans un nouveau coffre avec seulement trois extensions principales. Données brutes : experiments/2026-09-03-apps-idle-startup/raw.csv.

Reproduire les mesures

Le banc d’essai, le corpus, les CSV bruts et les résultats JSON seront publiés avec la bêta dans un dépôt public de mesures sur GitHub. tools/perf/gate.sh <binary> :1 3 exécute le contrôle ; tools/perf/bench-apps.sh la comparaison. Si vos résultats diffèrent des nôtres de plus de 15 %, dites-le-nous ; nous publierons l’écart.

Dernière exécution : contrôle du 2026-09-03 sur le commit 04cf7dc, comparaison avec b17c3bf ; latence de frappe mesurée le 2026-09-02 sur la version M3. À relancer pour chaque version.