63 Mo : ce que coûte un éditeur de code Mac quand ce n'est pas un navigateur

Un éditeur, c'est l'application que l'on ne quitte jamais. Il reste toute la journée derrière le navigateur, la messagerie et la visioconférence, à garder vos phrases inachevées. Quoi qu'il coûte, il le coûte en permanence, et sur la machine où vous vouliez aussi compiler quelque chose.

Nous avons donc mesuré MeatPad au lieu de spéculer, sur un Mac de travail ordinaire où tout le reste continuait de tourner.

Les chiffres

Trois scénarios, une machine, un après-midi :

MeatPad 0.10.2 · macOS 26.5.2 · Apple silicon

fenêtre de notes ouverte, 19 h            63 Mo    pic 83 Mo
projet de 2 721 fichiers, 6 onglets      108 Mo    pic 131 Mo
un seul fichier texte de 6,3 Mo         1500 Mo    voir la section honnête

VS Code 1.130.0, même dossier, mêmes 6 fichiers
                                         710 Mo    répartis sur 8 processus

C'est la ligne du milieu qui compte, car c'est la configuration de travail : un vrai dépôt avec son arborescence, six onglets ouverts, coloration syntaxique, recherche sur tout le projet et complétion actives. Elle se stabilise à 108 Mo et y reste. Le pic de 131 Mo correspond au premier passage sur le projet, qui construit l'index des identifiants pour la complétion, et cette mémoire est aussitôt rendue.

La ligne VS Code sert de contraste, pas de verdict : un répertoire utilisateur neuf, aucune extension installée, le même dossier et les mêmes six fichiers, mesurés une minute après le lancement. VS Code fait bien plus que MeatPad, et une grande part de cette différence, c'est l'écosystème d'extensions que beaucoup veulent à juste titre. La comparaison porte sur le plancher, pas sur le vainqueur.

Vérifiez vous-même, et méfiez-vous du mauvais chiffre

Deux outils de votre Mac se contredisent ici, et un seul a raison. Pendant que MeatPad annonçait 63 Mo, ps indiquait 147 Mo pour le même processus au même instant :

$ ps -o rss= -p $(pgrep -x MeatPad)
  150304

$ footprint -p $(pgrep -x MeatPad)
    phys_footprint: 63 MB
    phys_footprint_peak: 83 MB

La resident set size compte chaque page projetée dans le processus, y compris les pages partagées, en lecture seule et en copie sur écriture d'AppKit, SwiftUI, CoreText et du reste du système. Ces pages ne résident qu'une fois pour tout le Mac et ne sont facturées à personne. L'empreinte physique ne compte que ce dont ce processus est réellement responsable, et c'est aussi le chiffre affiché par le Moniteur d'activité dans sa colonne Mémoire. Quand quelqu'un cite une consommation mémoire pour une application Mac native, demandez laquelle des deux il a mesurée.

Raison un : il n'y a pas de navigateur dans le processus

MeatPad est une application native : Swift, AppKit et SwiftUI, 92 fichiers source et environ quinze mille cinq cents lignes, paquet de framework compris. Pas de Chromium, pas d'environnement JavaScript, pas de processus Node, pas d'hôte d'extensions, aucune copie privée d'une boîte à outils d'interface embarquée dans le bundle.

C'est là toute l'astuce des cent premiers mégaoctets. Un éditeur bâti sur une pile web doit emmener un navigateur au travail, et un navigateur est un système d'exploitation avec ses propres idées : son moteur de rendu, son ramasse-miettes, un processus par fenêtre, sa copie de tout. Avant d'afficher un seul caractère de votre code, il a déjà tout payé. Une application native emprunte le moteur de mise en page, le moteur de texte et la boîte à outils à la machine, où ils étaient déjà chargés pour le Finder.

Raison deux : l'éditeur ne compose que les lignes visibles

C'est dans la mise en page du texte que les éditeurs dérapent en silence. Mesurer chaque ligne d'un long document, à la police et à la largeur exactes, pour qu'une barre de défilement ait la bonne hauteur, cela fait beaucoup de travail avant de montrer quoi que ce soit.

MeatPad s'appuie sur STTextView et TextKit 2, la pile de texte actuelle d'Apple, qui travaille par fenêtre visible. Elle compose les fragments à l'écran et un peu au-delà, puis les oublie dès qu'ils sortent. Ouvrir un fichier, c'est le lire et dessiner un écran. Le coût du reste du document est différé jusqu'à ce que vous y défiliez, et libéré quand vous vous en éloignez.

Raison trois : vos notes sont des fichiers sur le disque, pas une base de données en mémoire

Chaque note est un simple fichier texte accompagné d'un petit fichier JSON. L'application ne charge pas un espace de travail en mémoire pour y habiter. Seuls les documents réellement ouverts gardent leur texte, et fermer une fenêtre le rend.

Le même réflexe traverse les fonctions de projet :

• L'arborescence lit d'abord un seul niveau, pour que la fenêtre s'affiche immédiatement, puis échange l'arbre complet dès qu'il est prêt.
• La recherche sur tout le projet lit les fichiers depuis le disque, en parallèle, au moment de la recherche. Aucun index de recherche persistant ne dort en mémoire entre deux recherches, car le disque est rapide et votre projet n'est pas si gros.
• L'index de complétion stocke le décompte des identifiants par fichier plutôt que le contenu des fichiers, et ignore tout ce qui dépasse quatre mégaoctets.
• La coloration syntaxique repose sur tree-sitter : des analyseurs compacts écrits en C, un arbre par document ouvert, mis à jour de façon incrémentale pendant la frappe plutôt que reconstruit.

Raison quatre : l'intelligence coûteuse vit dans un autre processus

L'intelligence d'un éditeur coûte vraiment cher. Un serveur de langage conserve un modèle sémantique de tout votre projet, et pour une grosse base de code Rust ou Swift ce modèle écrase tout ce qu'un éditeur fait avec du texte.

MeatPad n'héberge pas ce travail. Il parle le Language Server Protocol à des serveurs déjà installés sur votre machine, SourceKit-LSP, rust-analyzer, Pyright, chacun dans son propre processus, lancé à l'ouverture d'un projet et arrêté à sa fermeture. Ce que coûte le modèle sémantique est facturé au serveur, visible sous son propre nom dans le Moniteur d'activité, et récupéré dès que vous fermez le projet. L'éditeur garde les messages, pas le modèle. Si aucun serveur n'est installé, la complétion se rabat sur les identifiants du projet ouvert et tout le reste continue de fonctionner.

C'est aussi pour cela que les chiffres ci-dessus sont honnêtes plutôt que commodes. Ils ne sont pas bas parce que des fonctions auraient été retirées et poussées dans un autre processus pour les cacher. Ils sont bas parce que les parties qui ont besoin de beaucoup de mémoire ont le droit d'avoir la leur.

Là où cette conception mord

La troisième ligne du tableau n'était pas une coquille. Ouvrez un seul fichier texte de 6,3 Mo, environ cent vingt-neuf mille lignes, et MeatPad dépasse le gigaoctet et sature un cœur.

La cause n'est pas le moteur de texte, qui se comporte exactement comme annoncé. C'est la barre d'état. Elle affiche le nombre de lignes, de mots et de caractères du document, et calcule les trois en parcourant tout le texte à chaque passe de mise en page de l'interface. Sur une note ou un fichier source, cela représente quelques kilo-octets et personne ne le remarque. Sur cent vingt-neuf mille lignes, chaque passe de mise en page devient un parcours complet de six mégaoctets de texte, et l'interface se remet en page très souvent.

Le correctif est petit, il faut calculer ces compteurs une fois quand le texte change plutôt qu'une fois par rendu, et il est dans la file. Nous l'écrivons ici au lieu de l'omettre, car un article sur la mémoire qui ne cite que les bonnes mesures est une publicité. Les fichiers de tous les jours, ceux que l'on ouvre vraiment dans un éditeur, tiennent dans les deux premières lignes. Les très gros fichiers uniques sont la frontière, et c'est à nous de la corriger.

Pourquoi cela vaut un après-midi

La plupart des Mac vendus ont 16 Go de mémoire, et rares sont ceux qui ont un gigaoctet à perdre : le navigateur a trente onglets, l'outil de design est ouvert, quelque chose compile. La mémoire que garde un éditeur est de la mémoire que le compilateur ne peut pas utiliser, et quand elle manque, macOS se met à compresser et à échanger, ce que vous ressentez comme un tout légèrement pire d'un coup.

Une application native qui emprunte les frameworks du système, ne compose que le visible, laisse vos documents sous forme de fichiers et laisse les serveurs de langage tourner dans leurs propres processus finit autour de 63 Mo sans que personne n'ait optimisé quoi que ce soit. Ce n'est pas une histoire d'ingénierie héroïque. C'est le résultat ordinaire de ne pas avoir commencé par construire un navigateur.