Liczby, których pomiar można odtworzyć.

Środowisko

Każdy wynik na tej stronie pochodzi z jednego komputera: laptopa, na którym powstaje aplikacja, ze zwykłym zintegrowanym układem graficznym. Wersja na Windows nie była tu jeszcze mierzona, a wersja na macOS jest w przygotowaniu. Ich wiersze pojawią się tutaj, gdy będą dostępne.

Dokument testowy: tools/perf/fixtures/doc100k.md (100 KB, 874 wiersze) · 3 przebiegi, mediana · wskaźnik poza oknem · prawdziwa magistrala sesji.

Klatki w bezczynności

Deklaracja: gdy nic się nie dzieje, mori niczego nie rysuje. Przy dokumencie otwartym w widoku Live, bez fokusu na edytorze (aby kursor nie migał) i bez danych wejściowych przez 10 sekund (t = 5–15 s od uruchomienia) liczymy migawki samego edytora: każde żądanie rysowania edytora przez GTK.

Przy włączonym miganiu kursora (domyślnie, gdy okno ma fokus) edytor jest przerysowywany raz na każde mignięcie — zmienia się tylko kursor — i przestaje natychmiast po utracie fokusu przez okno. To jedyny cykliczny licznik dozwolony w aplikacji. Podczas bezczynności nie ma żadnego innego powtarzającego się źródła.

Opóźnienie danych wejściowych

Twierdzenie: 18.2 ms od klawisza do piksela, w 95. percentylu. Mierzone spoza procesu przez tools/perf/index/e2e_latency.sh: klawisz wstrzykiwany przez XTest, a ekran odpytywany aż zmieni się wiersz z kursorem. Dokument 100 KB, widok Live, 2560×1440 przy 180 Hz. Na 119 uderzeń: p50 14.1, p95 18.2, p99 19.1, maks. 20.4 ms.

Liczba obejmuje wszystko między klawiszem a pikselem: bibliotekę interfejsu, kompozytor i czekanie na następną klatkę. To czekanie wypada gdziekolwiek między zerem a jednym interwałem odświeżania — przy 180 Hz najwyżej 5,6 ms, średnio 2,8 — dlatego można ją zestawiać tylko z innym edytorem mierzonym przy tym samym odświeżaniu. Czas reakcji samego ekranu nie jest wliczony; nie mierzyliśmy go.

Zimny start

Twierdzenie: 387 ms od uruchomienia do okna, z otwartym plikiem 100 KB i pustą pamięcią podręczną. Zimny start to nowy proces i wyczyszczony page cache: binarium, biblioteki i plik czytane są z dysku. Przy ciepłym cache — czyli na co dzień — to samo uruchomienie zajmuje 259 ms. Zegar rusza przy exec i zatrzymuje się, gdy pojawia się okno; pierwsze rysowanie to ten sam zegar zatrzymany na pierwszym narysowaniu dokumentu.

Metoda: tools/perf/run-index.sh, zimny = nowy proces z wyczyszczonym page cache, plik 100 KB otwarty przy starcie, pięć przebiegów. Pamięć to PSS odczytany z /proc, gdy dokument jest już złożony, a aplikacja przeszła w spoczynek, minus ten sam odczyt z pustym dokumentem — czyli tyle kosztuje nas sam dokument: 9,4 MB z 70 MB. Reszta to podłoga biblioteki interfejsu i GPU, którą płaci każda aplikacja GTK4 na tej maszynie; zmienia się ze sterownikiem, dlatego publikujemy naszą część. Binarium ma 6.1 MB. Pierwsze rysowanie odczytujemy z licznika klatek samego edytora, który ma tylko nasza kompilacja dev — pozostałe trzy pokazują kreskę zamiast zgadywania.

Ten sam komputer, ten sam dokument

Typora, Obsidian i MarkText, każdy otwarty na tym samym dokumencie 100 KB w swoim widoku edycji w miejscu (WYSIWYG Typory, Live Preview Obsidiana, MarkText), na maszynie powyżej i w tym samym przebiegu co nasze liczby. Pamięć to PSS całego drzewa procesów, gdy dokument jest złożony, a aplikacja w spoczynku; CPU w spoczynku to CPU drzewa przez trzydzieści sekund przy oknie z fokusem i bez wpisywania; CPU pisania to CPU drzewa podczas wpisywania około 700 znaków w ludzkim tempie, po jednym co 150 ms.

Silniki rozchodzą się najpierw w spoczynku: przy otwartym oknie i braku pracy mori nie zużywa mierzalnego CPU i budzi się zero razy na sekundę, podczas gdy trzy edytory Electron siedzą na 1,1–1,6 % i 29–75 wybudzeniach. Potem pisanie: ułamek rdzenia wobec jednej trzeciej do dwóch trzecich. I wreszcie pamięć: jeden proces wobec sześciu do dziewięciu, 70 MB wobec 346–457.

MarkText działał z --no-sandbox (jego piaskownica nie startuje na tym jądrze); Obsidian działał w osobnym katalogu danych użytkownika. Dane surowe: tools/perf/results/2026-09-09-linux-myasus-180hz.json.

Odtwórz pomiary

Skrypty pomiarowe i plik wyniku są w repozytorium; publiczne repozytorium z korpusem i danymi surowymi jest w przygotowaniu i nie ma jeszcze daty. tools/perf/run-index.sh uruchamia wszystkie wskaźniki, tools/perf/check.sh sprawdza wynik względem budżetów. Jeśli Twoje liczby różnią się od naszych o więcej niż 15 %, napisz do nas; opublikujemy tę różnicę.

Ostatni przebieg: 2026-09-09, jedno uruchomienie tools/perf/run-index.sh na commicie 183cc22 — każda liczba na tej stronie, nasza i innych edytorów, pochodzi z tego jednego przebiegu. Powtarzane przy każdym wydaniu.