Dlaczego zamiast mówić, że jest lekki, publikujemy konkretne liczby
W stwierdzeniu, że coś jest lekkie, nie ma niczego, co można zweryfikować. mote określa osiem liczb, które mają mówić o aplikacji, i publikuje je wraz z metodami pomiaru, warunkami oraz surowymi danymi.
Edytory Markdown często przedstawia się tak.
Szybki. Lekki. Płynny.
Ale jeśli przy liczbach brakuje warunków, nie różnią się one od przymiotników. Kiedy i jak długo mierzono użycie CPU w stanie bezczynności. Od którego do którego momentu obliczano czas uruchamiania. Liczb uzyskanych w różnych warunkach nie da się bowiem porównywać.
Dlatego ustaliliśmy osiem wskaźników wydajności, które publikuje mote. Dla każdego wskaźnika zapisaliśmy metodę i warunki pomiaru, elementy wykluczone, zasady porównywania, kwestie wymagające uwagi oraz budżet. Do każdego dołączyliśmy również skrypt pomiarowy.
Dokumentacja, wyniki i kod używają tych samych nazw. Dzięki temu można od razu prześledzić, skąd pochodzi dana liczba.
Liczbom muszą towarzyszyć warunki
mote przestrzega czterech zasad.
Dla każdego pomiaru zapisujemy razem wartość, jednostkę, statystykę, liczbę próbek oraz próbki surowe. Wyniki bez jednostki są odrzucane na etapie kontroli.
Nie zapisujemy wartości, których nie zmierzyliśmy. Jeśli czegoś nie można zmierzyć, pozostawiamy puste miejsce i podajemy przyczynę. Nie wypełniamy go wartością szacunkową.
Porównujemy tylko wyniki z tej samej maszyny i tej samej sesji. Nie zestawiamy obok siebie liczb uzyskanych innego dnia lub na innym urządzeniu.
Warunki pomiaru również publikujemy razem z liczbami. W szczególności zawsze podajemy częstotliwość odświeżania i zarządcę częstotliwości CPU. Jeśli te warunki są różne, nie da się prawidłowo porównać opóźnienia ani czasu uruchamiania.
Nie tworzyliśmy nowych metod pomiaru.
Opóźnienie od naciśnięcia klawisza do zmiany obrazu mierzymy dokładnie metodą zastosowaną przez Pavla Fatina w Typometerze. Wprowadzamy klawisz spoza aplikacji i sprawdzamy, ile czasu upływa do zmiany piksela. Czas uruchamiania, podobnie jak w VS Code, podzieliliśmy na etapy oraz rozróżniliśmy uruchomienie zimne i ciepłe.
Zasada, że opóźnienie należy mierzyć od końca do końca, a nie wewnątrz frameworka, pochodzi z artykułu Dana Luu.
Porównaliśmy aplikacje bezpośrednio w tych samych warunkach
Nie cytowaliśmy pochodzących z innych miejsc danych o wydajności konkurencyjnych aplikacji. Zmierzyliśmy je samodzielnie na tym samym laptopie.
Otworzyliśmy ten sam dokument o rozmiarze 100 KB i uruchomiliśmy każdą aplikację siedem razy za pomocą tego samego skryptu. We wszystkich użyliśmy widoku edycji bezpośredniej i ustawiliśmy wskaźnik w tym samym miejscu.
Całkowite użycie pamięci przez procesy wyglądało następująco.
- mote: 78 MB
- Typora: 453 MB
- Obsidian: 361 MB
- MarkText: 416 MB
Użycie CPU podczas pisania, liczone względem jednego rdzenia, wynosiło odpowiednio 10,9%, 103%, 152% i 136%. Liczba procesów wynosiła odpowiednio 1, 8, 7 i 6.
mote używał od 4,6 do 5,8 raza mniej pamięci. Podczas pisania używał od 9,4 do 14 razy mniej CPU.
Pamięć obliczaliśmy jako PSS, a nie RSS. RSS może wielokrotnie uwzględniać pamięć współdzieloną przez kilka procesów. PSS dzieli pamięć współdzieloną przez liczbę procesów. Jest to również metoda stosowana przez monitor systemu.
Zachowaliśmy bez zmian również niekorzystne liczby
Gdy aplikacje były jedynie otwarte, użycie CPU wynosiło 0,0% dla mote, 0,1% dla Typory, 0,8% dla Obsidiana i 0,6% dla MarkTextu.
Typora także niemal nie używała CPU w stanie bezczynności. Dlatego nie możemy przedstawiać „nierobienia niczego po pozostawieniu otwartej aplikacji” jako przewagi nad Typorą.
Powłoka webowa używała 3,6%, a więc wypadała nawet gorzej od Typory.
Usuwanie cyklicznych liczników czasu działających wewnątrz aplikacji nadal jest ważne. Jednak zasada, której należy przestrzegać, i przewaga konkurencyjna to dwie różne kwestie.
Liczby klatek w stanie bezczynności nie porównywaliśmy z konkurencyjnymi aplikacjami. Celem mote jest 0 klatek w ciągu 10 sekund, ale inne aplikacje nie mają licznika klatek, który można sprawdzić w ten sam sposób.
Dlatego pola konkurencyjnych aplikacji pozostawiliśmy puste. Puste pole nie oznacza zera.
Jeśli czegoś nie da się porównać, nie porównujemy tego
Sprawdzamy również, czy po otwarciu pliku i zapisaniu go bez żadnych zmian oryginał pozostaje nienaruszony.
mote sprawdza 652 przykłady CommonMark. Otwieramy też i ponownie zapisujemy wszystkie dokumenty w repozytorium, a następnie sprawdzamy, czy są identyczne bajt po bajcie. Jeśli choć jeden się różni, traktujemy to nie jako problem z wydajnością, lecz jako błąd powodujący utratę danych.
Nie zapisaliśmy wyników konkurencyjnych aplikacji. Automatyzacja procesu zapisywania w takich samych warunkach była zbyt trudna.
Przed pomiarem sprawdzamy również stan maszyny. Jeśli trwa kompilacja, nie rozpoczynamy pomiaru. Przeglądarkę blokujemy tylko wtedy, gdy rzeczywiście intensywnie używa CPU. Średnie obciążenie, bezczynność CPU, kryteria oceny oraz wartości z chwili pomiaru są zapisywane w wynikach.
Ta zasada powstała po tym, jak doświadczyliśmy niepowodzenia.
Gdy zmierzyliśmy czas uruchamiania przy pozostawionej otwartej przeglądarce intensywnie używającej CPU, wydawało się, że wydajność się pogorszyła. Kiedy naprzemiennie zmierzyliśmy poprzedni i bieżący commit przy takim samym obciążeniu, okazało się, że przyczyną nie była regresja w kodzie, lecz obciążenie maszyny.
Od tamtej pory nie oceniamy czasu uruchamiania wyłącznie na podstawie jednej wartości bezwzględnej.
Po przekroczeniu budżetu nie można wykonać scalania
Budżet wydajności nie jest celem zapisanym wyłącznie w dokumentacji. To kryterium, które trzeba spełnić, aby kompilacja zakończyła się powodzeniem.
Kryteria dzielimy na hard i report.
hard obejmuje pozycje, których wartości określono w dokumencie decyzyjnym. Jeśli choć jedna przekroczy limit, kontrola kończy się niepowodzeniem. Nie ma też osobnej procedury zatwierdzania wyjątków.
report obejmuje pozycje, dla których wciąż brakuje wystarczających podstaw albo na które duży wpływ mają ograniczenia platformy. Wartości są zapisywane, ale nie blokują kompilacji.
Jeśli kompilację blokują liczby pozbawione wystarczającego uzasadnienia, ludzie zaczynają unikać samych pomiarów. Dlatego jako bramki używamy wyłącznie pewnych kryteriów.
Skrypty pomiarowe, źródłowe pliki CSV i wynikowe pliki JSON przechowujemy razem w repozytorium. Uruchomienie tego samego skryptu w tych samych warunkach pozwala ponownie utworzyć tabelę. Przygotowujemy się również do opublikowania narzędzi pomiarowych i dokumentów testowych w publicznym repozytorium benchmarków.
Wybieranie wyłącznie korzystnych liczb nie jest jawnością.
Pokazanie razem tego, co i jak zmierzyliśmy, w jakich warunkach oraz czego nie udało się zmierzyć. Tak mote publikuje swoje liczby.