63 MB: Was ein Mac-Code-Editor kostet, wenn er kein Browser ist

Ein Editor ist das Programm, das man nie beendet. Er liegt den ganzen Tag hinter dem Browser, dem Mailprogramm und der Videokonferenz und hält Ihre unfertigen Sätze fest. Was immer er kostet, kostet er die ganze Zeit, und zwar auf genau der Maschine, auf der Sie nebenbei etwas kompilieren wollten.

Also haben wir MeatPad gemessen, statt zu spekulieren, auf einem ganz normalen Arbeits-Mac, auf dem alles andere weiterlief.

Die Zahlen

Drei Szenarien, eine Maschine, ein Nachmittag:

MeatPad 0.10.2 · macOS 26.5.2 · Apple Silicon

Notizfenster offen, 19 h Laufzeit         63 MB    Spitze 83 MB
Projekt mit 2.721 Dateien, 6 Tabs        108 MB    Spitze 131 MB
eine Textdatei mit 6,3 MB               1500 MB    siehe ehrlicher Abschnitt

VS Code 1.130.0, gleicher Ordner, gleiche 6 Dateien
                                         710 MB    auf 8 Prozesse verteilt

Die mittlere Zeile ist die entscheidende, denn sie ist die Arbeitskonfiguration: ein echtes Repository mit Dateibaum, sechs offenen Tabs, Syntaxhervorhebung, projektweiter Suche und aktiver Vervollständigung. Sie pendelt sich bei 108 MB ein und bleibt dort. Die Spitze von 131 MB ist der erste Durchlauf durch das Projekt, der den Bezeichnerindex für die Vervollständigung aufbaut, und dieser Speicher wird sofort wieder freigegeben.

Die VS-Code-Zeile dient dem Vergleich, nicht dem Urteil: ein frisches Benutzerverzeichnis, keine installierten Erweiterungen, derselbe Ordner und dieselben sechs Dateien, gemessen eine Minute nach dem Start. VS Code kann sehr viel mehr als MeatPad, und ein großer Teil dieses Unterschieds ist das Plug-in-Ökosystem, das viele zu Recht haben wollen. Der Vergleich zeigt die Untergrenze, nicht den Sieger.

Messen Sie selbst nach, und hüten Sie sich vor der falschen Zahl

Zwei Werkzeuge auf Ihrem Mac widersprechen sich hier, und nur eines hat recht. Während MeatPad 63 MB meldete, gab ps für denselben Prozess im selben Moment 147 MB an:

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

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

Die Resident Set Size zählt jede Seite, die in den Prozess eingeblendet ist, auch die gemeinsam genutzten, schreibgeschützten Copy-on-Write-Seiten von AppKit, SwiftUI, CoreText und dem restlichen System. Diese Seiten liegen genau einmal für den ganzen Mac im Speicher und werden niemandem berechnet. Der physische Speicherbedarf zählt nur das, wofür dieser Prozess tatsächlich verantwortlich ist, und genau diese Zahl zeigt auch die Aktivitätsanzeige in ihrer Speicherspalte. Wenn jemand eine Speicherzahl für eine native Mac-App nennt, fragen Sie, welche der beiden gemessen wurde.

Grund eins: In diesem Prozess steckt kein Browser

MeatPad ist eine native Anwendung: Swift, AppKit und SwiftUI, 92 Quelldateien und rund fünfzehneinhalbtausend Zeilen einschließlich des eigenen Framework-Pakets. Kein Chromium, keine JavaScript-Laufzeit, kein Node-Prozess, kein Plug-in-Host, keine private Kopie eines UI-Toolkits im Programmpaket.

Das ist der ganze Trick hinter den ersten hundert Megabyte. Ein Editor auf Web-Basis muss einen Browser mit zur Arbeit bringen, und ein Browser ist ein Betriebssystem mit eigener Meinung: eigene Layout-Engine, eigene Speicherbereinigung, ein eigener Prozess pro Fenster, eine eigene Kopie von allem. Bevor er ein einziges Zeichen Ihres Codes zeichnet, hat er all das bereits bezahlt. Eine native App leiht sich Layout-Engine, Text-Engine und Toolkit von der Maschine, wo sie ohnehin schon für den Finder geladen sind.

Grund zwei: Der Editor setzt nur die Zeilen, die Sie sehen

Beim Textsatz gehen Editoren leise in die Irre. Jede Zeile eines langen Dokuments in exakter Schrift und Breite zu vermessen, damit ein Scrollbalken die richtige Höhe bekommt, ist sehr viel Arbeit, bevor überhaupt irgendetwas zu sehen ist.

MeatPad zeichnet über STTextView auf TextKit 2, Apples aktuellem Text-Stack, der am sichtbaren Ausschnitt arbeitet. Er setzt die Fragmente, die auf dem Bildschirm sind und ein Stück darüber hinaus, und vergisst sie wieder, sobald sie verschwinden. Eine Datei zu öffnen heißt, sie zu lesen und einen Bildschirm voll zu zeichnen. Die Kosten für den Rest des Dokuments fallen erst an, wenn Sie dorthin scrollen, und werden wieder frei, wenn Sie weiterscrollen.

Grund drei: Ihre Notizen sind Dateien auf der Platte, keine Datenbank im Speicher

Jede Notiz ist eine gewöhnliche Textdatei mit einer kleinen JSON-Beilage daneben. Die App lädt keinen Arbeitsbereich in den Speicher, um darin zu leben. Nur die Dokumente, die tatsächlich geöffnet sind, halten ihren Text, und wer ein Fenster schließt, bekommt ihn zurück.

Derselbe Instinkt zieht sich durch die Projektfunktionen:

• Der Dateibaum liest zuerst nur eine Ebene ein, damit das Fenster sofort erscheint, und tauscht den vollständigen Baum ein, sobald er fertig ist.
• Die projektweite Suche liest die Dateien erst beim Suchen nebenläufig von der Platte. Zwischen zwei Suchen liegt kein dauerhafter Suchindex im Speicher, denn die Platte ist schnell und Ihr Projekt ist nicht so groß.
• Der Vervollständigungsindex speichert Bezeichnerhäufigkeiten pro Datei statt der Dateiinhalte und überspringt alles über vier Megabyte.
• Die Syntaxhervorhebung läuft über tree-sitter: kompakte, in C geschriebene Parser, ein Baum pro geöffnetem Dokument, beim Tippen inkrementell nachgeführt statt neu aufgebaut.

Grund vier: Die teure Intelligenz lebt in einem anderen Prozess

Editor-Intelligenz ist wirklich teuer. Ein Language Server hält ein semantisches Modell Ihres gesamten Projekts, und bei einer großen Rust- oder Swift-Codebasis stellt dieses Modell alles in den Schatten, was ein Editor mit Text anstellt.

MeatPad übernimmt diese Arbeit nicht selbst. Es spricht das Language Server Protocol mit Servern, die bereits auf Ihrer Maschine installiert sind, SourceKit-LSP, rust-analyzer, Pyright, jeder in einem eigenen Prozess, gestartet beim Öffnen eines Projekts und beendet beim Schließen. Was das semantische Modell kostet, wird dem Server berechnet, ist in der Aktivitätsanzeige unter dessen eigenem Namen sichtbar und wird in dem Moment frei, in dem Sie das Projekt schließen. Der Editor hält die Nachrichten, nicht das Modell. Ist kein Server installiert, greift die Vervollständigung auf Bezeichner aus dem offenen Projekt zurück, und alles andere funktioniert weiter.

Deshalb sind die Zahlen oben ehrlich und nicht bloß bequem. Sie sind nicht niedrig, weil Funktionen weggelassen und zum Verstecken in einen anderen Prozess geschoben wurden. Sie sind niedrig, weil genau die Teile, die viel Speicher brauchen, ihren eigenen bekommen dürfen.

Wo dieser Entwurf zubeißt

Die dritte Zeile der Tabelle war kein Tippfehler. Öffnen Sie eine einzelne Textdatei mit 6,3 MB, rund einhundertneunundzwanzigtausend Zeilen, und MeatPad klettert über ein Gigabyte und legt einen Rechenkern voll aus.

Die Ursache ist nicht die Text-Engine, die sich genau so verhält wie versprochen. Es ist die Statusleiste. Sie zeigt Zeilen, Wörter und Zeichen des Dokuments an und berechnet alle drei, indem sie bei jedem Layout-Durchgang der Oberfläche den gesamten Text durchläuft. Bei einer Notiz oder einer Quelldatei sind das ein paar Kilobyte, die niemandem auffallen. Bei einhundertneunundzwanzigtausend Zeilen wird daraus bei jedem Layout-Durchgang ein vollständiger Lauf über sechs Megabyte Text, und die Oberfläche legt sich sehr oft neu aus.

Die Korrektur ist klein, die Zählungen müssen einmal beim Ändern des Textes berechnet werden statt einmal pro Bilddurchlauf, und sie steht auf der Liste. Wir schreiben das hier auf, statt es wegzulassen, denn ein Speicherartikel, der nur die guten Messungen nennt, ist Werbung. Alltägliche Dateien, auf die Editoren tatsächlich gerichtet werden, stehen in den ersten beiden Zeilen. Sehr große Einzeldateien sind die offene Grenze, und sie zu richten ist unsere Aufgabe.

Warum das einen Nachmittag wert ist

Die meisten verkauften Macs haben 16 GB Speicher, und die wenigsten Menschen haben ein Gigabyte übrig: Der Browser hat dreißig Tabs, das Designwerkzeug ist offen, irgendetwas kompiliert. Speicher, den ein Editor hält, ist Speicher, den der Compiler nicht nutzen kann, und wenn er ausgeht, beginnt macOS zu komprimieren und auszulagern, was sich anfühlt, als würde alles gleichzeitig ein wenig schlechter.

Eine native App, die sich die Frameworks des Systems leiht, nur das Sichtbare setzt, Ihre Dokumente als Dateien belässt und Language Server in eigenen Prozessen laufen lässt, landet bei etwa 63 MB, ohne dass jemand irgendetwas optimiert hätte. Das ist keine heldenhafte Ingenieursgeschichte. Es ist das gewöhnliche Ergebnis davon, nicht zuerst einen Browser zu bauen.