Environment
Every figure on this page comes from one machine: the laptop the app is developed on, an ordinary integrated-graphics configuration. The Windows build has not been measured here yet and the macOS build is in development; their rows appear here when they exist.
| Machine | OS | Display | Notes |
|---|---|---|---|
| Laptop, Intel i5-11300H, 23 GB, Iris Xe (Mesa 25.2) | Ubuntu 24.04, GNOME on X11 | 2560×1440 @ 180 Hz | Release build 1.0.0, commit 183cc22 |
Test document: tools/perf/fixtures/doc100k.md (100 KB, 874 lines) · 3 runs, median · pointer parked outside the window · real session bus.
Idle frames
Claim: when nothing happens, mori draws nothing. With the document open in Live view, the editor unfocused (so the caret does not blink), and no input for 10 seconds (t = 5–15 s after launch), we count the editor's own snapshots: every time GTK asks the editor to draw.
| Platform | Frames in 10 s | CPU, avg | Method |
|---|---|---|---|
| Linux | 0 | 0.0% | Editor snapshot count via tools/perf/gate.sh |
With the caret blink enabled (the default while the window has focus), the count is one editor redraw per blink — only the caret changes — and it stops the moment focus leaves the window. That blink is the one timer the app is allowed to keep; there is no other repeating source while idle.
Input latency
Claim: 18.2 ms from keystroke to pixel, at the 95th percentile. Measured from outside the process by tools/perf/index/e2e_latency.sh: a key is injected with XTest and the screen is polled until the caret line changes. 100 KB document, Live view, 2560×1440 at 180 Hz. Over 119 keystrokes: p50 14.1 ms, p95 18.2 ms, p99 19.1 ms, max 20.4 ms.
The figure covers everything between the key and the pixel: the toolkit, the compositor, and the wait for the next frame. That wait lands anywhere between zero and one refresh interval — at 180 Hz, up to 5.6 ms and 2.8 on average — which is why this figure can only be set beside another editor measured at the same refresh rate. The display's own response time is not included; we have not measured it.
Cold start
Claim: 387 ms from launch to the window, with a 100 KB file open and nothing cached. Cold means a fresh process and a dropped page cache, so the binary, the libraries and the file all come off disk. With the cache warm — the everyday case — the same launch takes 259 ms. The clock starts at exec and stops when the window is mapped; first paint is the same clock stopped at the editor's first snapshot of the document.
| Editor | exec → window | Warm cache | First paint | Processes |
|---|---|---|---|---|
| mori | 387 ms | 259 ms | 377 ms | 1 |
| Typora | 814 ms | 511 ms | — | 9 |
| Obsidian | 2,975 ms | 2,862 ms | — | 7 |
| MarkText | 2,042 ms | 1,872 ms | — | 6 |
Method: tools/perf/run-index.sh, cold = fresh process with the page cache dropped, 100 KB file open at launch, five runs. Memory is PSS from /proc once the document is laid out and the app has gone idle, minus the same reading with an empty document — what the document itself costs us: 9.4 MB of the 70 MB read. The rest is the toolkit and GPU stack every GTK4 application on this machine pays; it moves with the driver, which is why the number we publish is our share of it. The binary is 6.1 MB. First paint is read from the editor's own frame counter, which only our dev build has — the other three show a dash rather than a guess.
Same machine, same document
Typora, Obsidian and MarkText, each opened on the same 100 KB document in its inline-editing view (Typora's WYSIWYG, Obsidian's Live Preview, MarkText), on the machine above, in the same run as our own figures. Memory is the PSS of the whole process tree once the document is laid out and the app has gone idle; idle CPU is the tree's CPU over thirty seconds with the window focused and no input; typing CPU is the tree's CPU while about 700 characters are typed at a human pace, one every 150 ms.
| Editor | Version | PSS | Idle CPU | Typing CPU | Processes |
|---|---|---|---|---|---|
| mori | 1.0.0, commit 183cc22 | 70 MB | 0.0% | 7.2% | 1 |
| Typora | 1.14.9 | 457 MB | 1.1% | 30.5% | 9 |
| Obsidian | 1.12.7 | 346 MB | 1.6% | 32.5% | 7 |
| MarkText | 0.20.0-rc.1 | 405 MB | 1.4% | 62.3% | 6 |
Idle is where the engines part first: with the window open and nothing happening, mori uses no measurable CPU and wakes up zero times a second, while the three Electron editors sit at 1.1–1.6 % and 29–75 wakeups. Typing is the second parting: a fraction of a core against a third to two thirds of one. And memory is the third: one process against six to nine, 70 MB against 346–457.
MarkText ran with --no-sandbox (its sandbox does not start on this kernel); Obsidian ran in a separate user-data directory. Raw data: tools/perf/results/2026-09-09-linux-myasus-180hz.json.
Reproduce it
The harness and the result file live in the repository; a public repository with the corpus and raw data is being prepared, and there is no date for it yet. tools/perf/run-index.sh runs every index; tools/perf/check.sh validates the result against the budgets. If your numbers differ from ours by more than 15 %, tell us; we publish the discrepancy.
Last run: 2026-09-09, a single run of tools/perf/run-index.sh against commit 183cc22 — every figure on this page, ours and the other editors', comes from that one run. Re-run on every release.