Umgebung
Alle Zahlen auf dieser Seite stammen von einem Rechner: dem Laptop, auf dem die App entwickelt wird, mit gewöhnlicher integrierter Grafik. Die Versionen für macOS und Windows sind in Entwicklung; ihre Zeilen erscheinen hier, sobald sie existieren.
| Rechner | Betriebssystem | Anzeige | Anmerkungen |
|---|---|---|---|
| Laptop, Intel i5-11300H, 23 GB, Iris Xe (Mesa 25.2) | Ubuntu 24.04, GNOME unter X11 | 2560×1440 @ 60 Hz | Release-Build, Commit 04cf7dc |
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 mote 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.
| Plattform | Frames in 10 s | CPU, Durchschnitt | Methode |
|---|---|---|---|
| Linux | 0 | 0.0% | Zahl der Editor-Snapshots über tools/perf/gate.sh |
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
Aussage: 9.7 ms vom Tastenanschlag bis zum Pixel, im 95. Perzentil. Tastenanschlag → verarbeitet: p95 0.29 ms. Tastenanschlag → Pixel (einschließlich VSync): p95 9.7 ms. Prozessintern mit tools/perf/typing.sh gemessen, Dokument mit 100 KB, Live-Ansicht.
„Verarbeitet“ bedeutet, dass das Eingabeereignis das Dokument aktualisiert und die betroffenen Layouts ungültig gemacht hat. „Pixel“ bezeichnet das Ende des nächsten Snapshots, der auf den Frame-Takt wartet und daher nach unten durch VSync begrenzt ist (16.7 ms bei 60 Hz). Über 300 Tastenanschläge lagen die beiden Verteilungen bei p50 0.01 / p95 0.29 / max 0.48 ms und p50 2.6 / p95 9.7 / max 12.7 ms. Gemessen am 2026-09-02 mit dem M3-Build, einem früheren Commit als der unten genannte Gate-Lauf. Der Tipplauf liegt noch nicht im Ergebnisverzeichnis; führen Sie ihn erneut aus, bevor Sie ihm vertrauen. Die Reaktionszeit des Displays selbst ist nicht enthalten; wir haben sie nicht gemessen.
Kaltstart
Aussage: 211 ms vom Start bis zum Fenster, bei geöffneter Datei mit 100 KB. „Kalt“ bedeutet einen neuen Prozess, der die Datei beim Start öffnet; nichts ist vorgewärmt, und der Seitencache bleibt unangetastet. Die Uhr beginnt bei exec und stoppt, sobald das Fenster abgebildet ist. Für das erste Bild wird dieselbe Uhr beim ersten Snapshot des Dokuments durch den Editor gestoppt.
| Plattform | exec → Fenster | Erstes Bild | Binärgröße | RSS (PSS) nach dem Laden |
|---|---|---|---|---|
| Linux | 211 ms | 231 ms | 3.1 MB | 69 MB |
Methode: tools/perf/gate.sh, kalt = neuer Prozess, Datei mit 100 KB beim Start geöffnet. PSS wird nach fünfzehn Sekunden aus /proc gelesen, sobald das Dokument gesetzt ist und die App in den Leerlauf gegangen ist.
Derselbe Rechner, dasselbe Dokument
Typora, Obsidian und MarkText wurden jeweils mit demselben Dokument mit 100 KB in ihrer Inline-Bearbeitungsansicht geöffnet (WYSIWYG von Typora, Live Preview von Obsidian, MarkText), auf dem oben genannten Rechner und mit demselben Skript. Der Speicherwert ist die PSS des gesamten Prozessbaums zwölf Sekunden nach dem Start. Die Leerlauf-CPU ist die CPU-Auslastung des Baums in den Sekunden 5–10 bei fokussiertem Fenster und ohne Eingabe. Die Tipp-CPU ist die CPU-Auslastung des Baums, während etwa 150 Zeichen im Abstand von jeweils 30 ms eingegeben werden. Sieben Durchläufe pro Editor, Mittelwert, nach einem verworfenen Aufwärmlauf.
| Editor | Version | PSS | Leerlauf-CPU | Tipp-CPU | Prozesse |
|---|---|---|---|---|---|
| mote | Vorabversion, Commit b17c3bf | 78 MB | 0.0% | 10.9% | 1 |
| Typora | 1.14.9 | 453 MB | 0.1% | 102.6% | 8 |
| Obsidian | 1.12.7 | 361 MB | 0.8% | 152.5% | 7 |
| MarkText | 0.19.1 | 416 MB | 0.6% | 135.8% | 6 |
Die Leerlauf-CPU von Typora ist ebenso niedrig wie unsere — das sagen wir auch. Chromium drosselt, wenn es wirklich nichts zu tun gibt. Die Leerlaufspalte unterscheidet mote daher von Obsidian und MarkText, nicht von Typora. Bei Speicher und Tippaufwand trennen sich die Engines: ein Prozess gegenüber sechs bis acht und ein Zehntel der CPU pro Tastenanschlag. Die hier genannten 78 MB liegen über den obigen 69 MB, weil sie den gesamten Prozessbaum einer anderen Sitzung erfassen. Der Grundbedarf von GTK und Mesa schwankt zwischen Sitzungen um etwa ein Dutzend Megabyte.
MarkText lief mit --no-sandbox (seine Sandbox startet auf diesem Kernel nicht); Obsidian lief in einem neuen Vault mit nur drei Kern-Plugins. Rohdaten: experiments/2026-09-03-apps-idle-startup/raw.csv.
Nachmessen
Testwerkzeug, Korpus, rohe CSV-Dateien und Ergebnis-JSON werden mit der Beta in einem öffentlichen Benchmark-Repository auf GitHub veröffentlicht. tools/perf/gate.sh <binary> :1 3 führt den Gate-Test aus, tools/perf/bench-apps.sh den Vergleich. Weichen Ihre Zahlen um mehr als 15 % von unseren ab, sagen Sie uns Bescheid; wir veröffentlichen die Abweichung.
Letzter Lauf: Gate 2026-09-03 gegen Commit 04cf7dc, Vergleich gegen b17c3bf; Tipplatenz 2026-09-02 mit dem M3-Build. Bei jeder Veröffentlichung erneut ausführen.