Zahlen, deren Messung Sie nachvollziehen können.

Umgebung

Alle Zahlen auf dieser Seite stammen von einem Rechner: dem Laptop, auf dem die App entwickelt wird, mit gewöhnlicher integrierter Grafik. Die Version für Windows wurde hier noch nicht gemessen, die Version für macOS ist in Entwicklung; ihre Zeilen erscheinen hier, sobald es sie gibt.

Testdokument: tools/perf/fixtures/doc100k.md (100 KB, 874 Zeilen) · 3 Durchläufe, Median · Zeiger außerhalb des Fensters geparkt · echter Session-Bus.

Leerlauf-Frames

Aussage: Wenn nichts geschieht, zeichnet mori nichts. Bei geöffnetem Dokument in der Live-Ansicht, ohne Fokus im Editor (damit der Cursor nicht blinkt) und ohne Eingabe für 10 Sekunden (t = 5–15 s nach dem Start) zählen wir die Snapshots des Editors selbst: jedes Mal, wenn GTK den Editor zum Zeichnen auffordert.

Bei aktiviertem Cursorblinken (Standard, solange das Fenster den Fokus hat) erfolgt pro Blinken genau eine Neuzeichnung des Editors — nur der Cursor ändert sich. Sobald das Fenster den Fokus verliert, endet sie. Dieses Blinken ist der einzige wiederkehrende Timer, den die App behalten darf; im Leerlauf gibt es keine weitere periodische Quelle.

Eingabelatenz

Behauptung: 18.2 ms vom Tastendruck bis zum Pixel, im 95. Perzentil. Gemessen von außerhalb des Prozesses durch tools/perf/index/e2e_latency.sh: Eine Taste wird per XTest eingespeist und der Bildschirm abgefragt, bis sich die Zeile mit dem Cursor ändert. 100-KB-Dokument, Live-Ansicht, 2560×1440 bei 180 Hz. Über 119 Tastendrücke: p50 14.1, p95 18.2, p99 19.1, max 20.4 ms.

Die Zahl umfasst alles zwischen Taste und Pixel: Toolkit, Compositor und das Warten auf das nächste Bild. Dieses Warten fällt irgendwohin zwischen null und ein Bildintervall — bei 180 Hz höchstens 5.6 ms, im Mittel 2.8 — weshalb sich diese Zahl nur neben einen anderen Editor stellen lässt, der bei derselben Bildwiederholrate gemessen wurde. Die Reaktionszeit des Displays selbst ist nicht enthalten; wir haben sie nicht gemessen.

Kaltstart

Behauptung: 387 ms vom Start bis zum Fenster, mit einer geöffneten 100-KB-Datei und nichts im Cache. Kalt heißt: frischer Prozess und geleerter Page Cache, Binärdatei, Bibliotheken und Datei kommen alle von der Platte. Mit warmem Cache — dem Alltagsfall — dauert derselbe Start 259 ms. Die Uhr startet bei exec und stoppt, wenn das Fenster erscheint; der erste Paint ist dieselbe Uhr, gestoppt beim ersten Zeichnen des Dokuments.

Methode: tools/perf/run-index.sh, kalt = frischer Prozess mit geleertem Page Cache, 100-KB-Datei beim Start geöffnet, fünf Durchläufe. Der Speicher ist PSS aus /proc, sobald das Dokument gesetzt ist und die App im Leerlauf liegt, minus derselben Messung mit leerem Dokument — was das Dokument selbst uns kostet: 9.4 MB von 70 MB. Der Rest ist der Toolkit- und GPU-Sockel, den jede GTK4-Anwendung auf dieser Maschine zahlt; er bewegt sich mit dem Treiber, und deshalb veröffentlichen wir unseren Anteil daran. Die Binärdatei ist 6.1 MB groß. Den ersten Paint liest der Editor aus seinem eigenen Frame-Zähler, den nur unser Dev-Build hat — bei den anderen dreien steht ein Strich statt einer Schätzung.

Derselbe Rechner, dasselbe Dokument

Typora, Obsidian und MarkText, jeweils mit demselben 100-KB-Dokument in ihrer Inline-Editieransicht geöffnet (Typoras WYSIWYG, Obsidians Live Preview, MarkText), auf der Maschine oben, im selben Lauf wie unsere eigenen Zahlen. Der Speicher ist der PSS des gesamten Prozessbaums, sobald das Dokument gesetzt ist und die App im Leerlauf liegt; die Leerlauf-CPU ist die CPU des Baums über dreißig Sekunden mit fokussiertem Fenster und ohne Eingabe; die Tipp-CPU ist die CPU des Baums, während rund 700 Zeichen in menschlichem Tempo getippt werden, eines alle 150 ms.

Zuerst trennen sich die Engines im Leerlauf: Fenster offen, nichts los — mori braucht keine messbare CPU und wacht null Mal pro Sekunde auf, während die drei Electron-Editoren bei 1.1–1.6 % und 29–75 Weckvorgängen liegen. Als Zweites das Tippen: ein Bruchteil eines Kerns gegen ein Drittel bis zwei Drittel. Als Drittes der Speicher: ein Prozess gegen sechs bis neun, 70 MB gegen 346–457.

MarkText lief mit --no-sandbox (seine Sandbox startet auf diesem Kernel nicht); Obsidian lief in einem eigenen User-Data-Verzeichnis. Rohdaten: tools/perf/results/2026-09-09-linux-myasus-180hz.json.

Nachmessen

Harness und Ergebnisdatei liegen im Repository; ein öffentliches Repository mit Korpus und Rohdaten ist in Vorbereitung, ein Datum gibt es dafür noch nicht. tools/perf/run-index.sh führt alle Indizes aus, tools/perf/check.sh prüft das Ergebnis gegen die Budgets. Weichen Ihre Zahlen um mehr als 15 % von unseren ab, sagen Sie uns Bescheid; wir veröffentlichen die Abweichung.

Letzter Lauf: 2026-09-09, ein einziger Lauf von tools/perf/run-index.sh gegen Commit 183cc22 — jede Zahl auf dieser Seite, unsere wie die der anderen Editoren, stammt aus diesem Lauf. Wird zu jedem Release wiederholt.