Testy wydajności

Środowisko

Każdy wynik na tej stronie pochodzi z jednego komputera: laptopa, na którym powstaje aplikacja, ze zwykłym zintegrowanym układem graficznym. Wersje na macOS i Windows są w przygotowaniu. Ich wiersze pojawią się tutaj, gdy będą dostępne.

Komputer	System	Ekran	Uwagi
Laptop, Intel i5-11300H, 23 GB, Iris Xe (Mesa 25.2)	Ubuntu 24.04, GNOME na X11	2560×1440 @ 60 Hz	Kompilacja wydania, commit `04cf7dc`

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, mote 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.

Platforma	Klatki w 10 s	CPU, średnio	Metoda
Linux	`0`	0.0%	Liczba migawek edytora przez `tools/perf/gate.sh`

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

Deklaracja: 9.7 ms od naciśnięcia klawisza do piksela, w 95. percentylu. Klawisz → przetworzenie: p95 0.29 ms. Klawisz → piksel (łącznie z vsync): p95 9.7 ms. Pomiar wewnątrz procesu przez tools/perf/typing.sh, dokument 100 KB, widok Live.

„Przetworzenie” oznacza, że zdarzenie wejściowe zaktualizowało dokument i unieważniło zmienione układy. „Piksel” oznacza koniec następnej migawki, która czeka na zegar klatek, więc jej dolną granicę wyznacza vsync (16.7 ms przy 60 Hz). Dla 300 naciśnięć klawiszy rozkłady wyniosły p50 0.01 / p95 0.29 / max 0.48 ms oraz p50 2.6 / p95 9.7 / max 12.7 ms. Pomiar wykonano 2026-09-02 na kompilacji M3, wcześniejszym commicie niż poniższy przebieg bramki. Wynik pisania nie znajduje się jeszcze w katalogu wyników, więc przed uznaniem go za wiarygodny należy powtórzyć test. Czas reakcji samego ekranu nie jest uwzględniony; nie mierzyliśmy go.

Zimny start

Deklaracja: 211 ms od uruchomienia do pojawienia się okna, z otwartym plikiem 100 KB. Zimny start oznacza nowy proces z plikiem otwieranym podczas uruchamiania. Nic nie jest wstępnie rozgrzane, a pamięć podręczna stron pozostaje bez zmian. Pomiar zaczyna się przy exec i kończy po zmapowaniu okna. Pierwsze rysowanie korzysta z tego samego zegara i kończy się przy pierwszej migawce dokumentu wykonanej przez edytor.

Platforma	exec → okno	Pierwsze rysowanie	Rozmiar pliku binarnego	RSS (PSS) po wczytaniu
Linux	211 ms	231 ms	3.1 MB	69 MB

Metoda: tools/perf/gate.sh, zimny = nowy proces, plik 100 KB otwierany przy uruchomieniu. PSS jest odczytywane z /proc po piętnastu sekundach, gdy dokument jest już ułożony, a aplikacja przeszła w stan bezczynności.

Ten sam komputer, ten sam dokument

Typora, Obsidian i MarkText otwarto z tym samym dokumentem 100 KB w ich widokach edycji bezpośredniej (WYSIWYG w Typora, Live Preview w Obsidian, MarkText), na opisanym wyżej komputerze i za pomocą tego samego skryptu. Pamięć to PSS całego drzewa procesów dwanaście sekund po uruchomieniu. CPU w bezczynności to użycie CPU przez drzewo procesów między sekundą 5 a 10, przy aktywnym oknie i bez danych wejściowych. CPU podczas pisania to użycie CPU przez drzewo podczas wpisywania około 150 znaków, po jednym co 30 ms. Siedem przebiegów na edytor, średnia, po odrzuceniu jednego przebiegu rozgrzewkowego.

Edytor	Wersja	PSS	CPU w bezczynności	CPU podczas pisania	Procesy
mote	wersja przedpremierowa, 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

Zużycie CPU przez Typora w bezczynności jest równie niskie jak u nas — mówimy o tym wprost. Chromium ogranicza pracę, gdy rzeczywiście nic się nie dzieje, więc kolumna bezczynności odróżnia mote od Obsidian i MarkText, ale nie od Typora. Różnicę między silnikami widać w pamięci i koszcie pisania: jeden proces zamiast od sześciu do ośmiu oraz jedna dziesiąta użycia CPU na naciśnięcie klawisza. Widoczne tutaj 78 MB jest wyższe niż 69 MB powyżej, ponieważ obejmuje całe drzewo procesów i pochodzi z innej sesji. Bazowe zużycie GTK i Mesa różni się między sesjami o kilkanaście megabajtów.

MarkText uruchomiono z --no-sandbox (jego piaskownica nie uruchamia się na tym jądrze). Obsidian działał w nowym magazynie z zaledwie trzema wtyczkami podstawowymi. Dane surowe: experiments/2026-09-03-apps-idle-startup/raw.csv.

Odtwórz pomiary

Zestaw testowy, korpus, surowe pliki CSV i wyniki JSON zostaną opublikowane wraz z betą w publicznym repozytorium testów na GitHub. tools/perf/gate.sh <binary> :1 3 uruchamia bramkę, a tools/perf/bench-apps.sh porównanie. Jeśli wyniki różnią się od naszych o więcej niż 15 %, daj nam znać; opublikujemy tę rozbieżność.