Comment nous avons fait en sorte qu’il n’utilise pas le processeur lorsqu’il reste simplement ouvert

L’éditeur est l’application qui reste ouverte le plus longtemps sur un ordinateur portable. Mais le temps réellement consacré à l’écriture n’est pas très long. La plupart du temps, il reste simplement ouvert en silence pendant que l’on fait autre chose.

C’est pourquoi mote a établi un principe.

Si le document ne change pas et qu’il n’y a aucune animation, ne rien faire.

Aucune frame programmée, aucun minuteur répétitif, aucune vérification périodique. Ce n’est pas une optimisation, mais un principe de conception à respecter avant toute fonctionnalité.

S’il ne se passe rien, 0 frame également

Il est difficile de savoir si une application est inactive en se fondant uniquement sur l’utilisation du CPU. La valeur fluctue à chaque mesure et peut facilement devenir 0 une fois arrondie.

C’est pourquoi mote regarde d’abord le nombre de frames. Si le document ne change pas pendant les 10 secondes qui suivent l’affichage de la fenêtre, le nombre de frames dessinées doit être exactement égal à 0. Elles sont comptées directement dans l’application, et si une seule est dessinée, le code n’est pas fusionné.

Même avec 0 frame, il ne faut pas se croire à l’abri. Des threads peuvent continuer à se réveiller en arrière-plan. Nous relevons donc également combien de fois par seconde chacun des threads du processus se réveille. Comme nous sommes encore en train d’établir une référence, ce chiffre ne bloque pas à lui seul le développement.

Le seul cas particulier est le clignotement du curseur. Il n’utilise pas de minuteur répétitif : après un clignotement, l’action suivante est programmée à nouveau. Il s’arrête immédiatement lorsque la fenêtre perd le focus. Le budget d’utilisation du CPU au repos, curseur compris, est de 0,3 %.

Nous n’examinons pas les performances au repos séparément. En retardant le rendu, il est facile d’obtenir 0 frame, mais les caractères saisis risquent alors d’apparaître en retard. Nous vérifions donc simultanément la latence de la saisie, la vitesse de démarrage et la mémoire. Si une seule limite est dépassée, le code n’est pas fusionné.

Une fois dans le code, une fois sur un appareil réel

Les principes s’estompent avec le temps. Nous les vérifions donc deux fois.

Nous inspectons d’abord le code. Nous recherchons automatiquement les minuteurs répétitifs, les ticks sans fin, le polling qui alterne sans cesse entre veille et réveil, ainsi que le code qui relit inutilement l’intégralité d’un fichier. Si l’un de ces éléments est détecté, la CI s’arrête à cet endroit. Si une exception est absolument nécessaire, il faut expliquer juste au-dessus du code pourquoi la tâche finit par se terminer.

Nous effectuons ensuite les mesures sur un appareil réel. Quatre conditions doivent alors être respectées.

Les mesures sont réalisées sur un véritable écran doté d’un GPU. Le pointeur est placé en dehors de la fenêtre. Une véritable session de bus est utilisée, et les frames sont comptées dès l’instant où elles sont dessinées.

Ces conditions sont nées de nos échecs. Il est déjà arrivé que 150 frames au repos soient produites simplement parce que le pointeur se trouvait au-dessus de la fenêtre. Dans une session isolée, le démarrage a été retardé de plusieurs secondes parce que la boîte à outils attendait une réponse. Lorsque nous utilisions un compteur de frames dont les données étaient rapportées tardivement, les frames de l’écran de démarrage se mélangeaient parfois à la période d’inactivité.

La mémoire n’est pas non plus évaluée en valeur absolue. La mémoire occupée par la boîte à outils et le pilote graphique varie de plusieurs dizaines de Mo selon l’environnement.

Nous prenons plutôt un document vide comme référence. Nous regardons uniquement combien de mémoire supplémentaire est utilisée à l’ouverture du document par rapport au document vide. Lors de la dernière mesure, le document vide utilisait 116 Mo et le document de 100 Ko, 120 Mo. La mémoire supplémentaire utilisée par mote s’élevait à 4 Mo, soit dans la limite du budget de 8 Mo.

Nous n’avons pas toujours procédé ainsi. Nous avons un jour pensé avoir dépassé le budget mémoire, avant de découvrir que ce n’était pas l’application, mais la consommation mémoire de base de l’environnement d’exécution qui avait augmenté. À partir de ce jour-là, nous avons commencé à mesurer « ce que nos fonctionnalités ont ajouté » plutôt qu’une valeur absolue.

Pendant le développement, le nombre de minuteurs actifs est également affiché à l’écran. S’il n’est pas égal à 0, nous pouvons le savoir immédiatement avant de faire un commit.

L’enregistrement automatique suit lui aussi ce principe. Un minuteur n’est programmé qu’une seule fois lorsque le document a changé, puis il est supprimé une fois l’enregistrement terminé. Il ne se réveille pas périodiquement pour vérifier : « Est-ce que quelque chose a changé ? »

Ces chiffres ne servent pas à battre la concurrence

Au début, nous voulions présenter les performances au repos comme un avantage par rapport à Typora. Mais nos propres mesures ont montré que ce n’était pas le cas.

Sur le même appareil et dans les mêmes conditions, l’utilisation du CPU au repos de Typora était de 0,1 %. Elle était pratiquement identique à celle de mote. Les applications pour lesquelles une différence a été confirmée étaient Obsidian, à 0,8 %, et MarkText, à 0,6 %.

Nous avons également déjà écrit quelque chose d’inexact. Pendant un certain temps, la documentation indiquait : « Typora utilise le CPU lorsqu’on le laisse ouvert. » Le chiffre de 34,6 % cité comme preuve ne correspondait pas à Typora, mais à une mesure d’apostrophe. Après vérification, nous avons immédiatement corrigé la phrase.

Les 0 frame au repos ne sont pas une affirmation dirigée contre la concurrence. C’est une discipline que mote s’impose à lui-même. Car s’il n’existe aucune tâche qui s’exécute en boucle, nous pouvons expliquer à tout moment ce que fait l’application.

Nous avons aussi renoncé à certaines choses à cause de ce principe

Il est souvent impossible d’utiliser la méthode la plus pratique.

Au lieu de vérifier périodiquement si un fichier a été modifié de l’extérieur, nous devons recevoir les notifications de modification du système d’exploitation. Au lieu de confier les formules à une webview, nous avons créé nous-mêmes un moteur de mise en page. Les animations ne peuvent pas non plus tourner en permanence. Chaque mouvement possède un début et une fin, et doit s’arrêter complètement une fois terminé.

Nous n’affirmerons pas que la batterie dure plusieurs heures de plus. Car c’est un chiffre que nous n’avons pas mesuré. Ce que nous avons vérifié, c’est le nombre de frames, l’utilisation du CPU et même le nombre de réveils des threads.

Ne rien faire quand il ne se passe rien.

Dans mote, ce n’est pas une fonctionnalité, mais un principe auquel toutes les fonctionnalités doivent se conformer.