Warum wir Zahlen veröffentlichen, statt nur zu sagen, dass es leichtgewichtig ist
An der Behauptung, etwas sei leichtgewichtig, gibt es nichts zu überprüfen. mote legt acht Zahlen fest, die für sich selbst sprechen sollen, und veröffentlicht dazu die Messmethoden, Bedingungen und Rohdaten.
Markdown-Editoren werden oft so vorgestellt.
Schnell. Leichtgewichtig. Flüssig.
Doch wenn bei Zahlen die Bedingungen fehlen, unterscheiden sie sich nicht von Adjektiven. Wann und wie lange die CPU-Auslastung im Leerlauf gemessen wurde. Von welchem bis zu welchem Zeitpunkt die Startzeit berechnet wurde. Denn Zahlen, die unter unterschiedlichen Bedingungen ermittelt wurden, lassen sich nicht vergleichen.
Deshalb haben wir acht Leistungskennzahlen festgelegt, die mote veröffentlicht. Für jede Kennzahl haben wir die Messmethode und die Bedingungen, Ausschlüsse, Vergleichsregeln, zu beachtende Punkte und das Budget dokumentiert. Außerdem haben wir jedes Messskript einzeln verlinkt.
Dokumentation, Ergebnisse und Code verwenden alle dieselben Bezeichnungen. So lässt sich sofort nachvollziehen, woher eine Zahl stammt.
Zu Zahlen gehören Bedingungen
mote hält sich an vier Grundsätze.
Für jeden Messwert speichern wir Wert und Einheit, Statistik, Stichprobengröße und Rohstichproben gemeinsam. Ergebnisse ohne Einheit werden bei der Prüfung abgelehnt.
Werte, die wir nicht gemessen haben, geben wir nicht an. Wenn etwas nicht messbar ist, lassen wir das Feld leer und nennen den Grund. Wir füllen es nicht mit Schätzwerten.
Vergleiche führen wir nur auf demselben Rechner und in derselben Sitzung durch. Zahlen von unterschiedlichen Tagen oder unterschiedlichen Geräten stellen wir nicht nebeneinander.
Auch die Messbedingungen veröffentlichen wir zusammen mit den Zahlen. Insbesondere geben wir immer die Bildwiederholrate und den CPU-Governor an. Wenn diese Bedingungen voneinander abweichen, lassen sich Latenz und Startzeit nicht korrekt vergleichen.
Wir haben keine neue Messmethode erfunden.
Die Latenz vom Tastendruck bis zur sichtbaren Änderung wird genau nach der Methode gemessen, die Pavel Fatins Typometer verwendet. Die Taste wird außerhalb der App ausgelöst und anschließend wird geprüft, wann sich ein Pixel verändert. Die Startzeit haben wir wie bei VS Code in einzelne Phasen unterteilt und zwischen Kalt- und Warmstart unterschieden.
Den Grundsatz, dass Latenz nicht innerhalb eines Frameworks, sondern durchgängig von Anfang bis Ende gemessen werden muss, haben wir aus einem Artikel von Dan Luu übernommen.
Wir haben unter denselben Bedingungen selbst verglichen
Für die Leistung konkurrierender Apps haben wir keine Zahlen aus anderen Quellen zitiert. Wir haben sie selbst auf demselben Notebook gemessen.
Wir haben dasselbe 100 KB große Dokument geöffnet und jede App siebenmal mit demselben Skript ausgeführt. Bei allen Apps wurde die Inline-Bearbeitungsansicht verwendet und auch die Zeigerposition identisch eingestellt.
Der Speicherverbrauch aller Prozesse zusammen sah so aus.
- mote: 78 MB
- Typora: 453 MB
- Obsidian: 361 MB
- MarkText: 416 MB
Die CPU-Auslastung beim Tippen betrug bezogen auf einen Kern 10,9 %, 103 %, 152 % beziehungsweise 136 %. Die Anzahl der Prozesse lag bei 1, 8, 7 beziehungsweise 6.
Der Speicherverbrauch von mote war um den Faktor 4,6 bis 5,8 geringer. Die beim Tippen benötigte CPU-Leistung war um den Faktor 9,4 bis 14 geringer.
Der Speicher wurde nicht als RSS, sondern als PSS berechnet. Bei RSS kann Speicher, den mehrere Prozesse gemeinsam nutzen, mehrfach gezählt werden. PSS teilt gemeinsam genutzten Speicher entsprechend der Anzahl der Prozesse auf. Das entspricht auch der Berechnungsweise von Systemmonitoren.
Auch ungünstige Zahlen haben wir unverändert stehen lassen
Wenn die Apps lediglich geöffnet waren, lag die CPU-Auslastung bei mote bei 0,0 %, bei Typora bei 0,1 %, bei Obsidian bei 0,8 % und bei MarkText bei 0,6 %.
Auch Typora beanspruchte die CPU im Leerlauf kaum. Deshalb können wir die Eigenschaft, „nichts zu tun, wenn die App nur geöffnet ist“, nicht als Vorteil gegenüber Typora darstellen.
Die Web-Shell verbrauchte 3,6 % und schnitt damit sogar schlechter als Typora ab.
Die Beseitigung wiederholt laufender Timer innerhalb der App bleibt wichtig. Aber ein Grundsatz, den man einhalten muss, und ein Wettbewerbsvorteil sind zwei verschiedene Dinge.
Die Frames im Leerlauf haben wir nicht mit konkurrierenden Apps verglichen. Das Ziel von mote sind 0 Frames innerhalb von 10 Sekunden, aber andere Apps verfügen über keinen Frame-Zähler, mit dem sich dies auf dieselbe Weise überprüfen ließe.
Deshalb haben wir die Felder der konkurrierenden Apps leer gelassen. Ein leeres Feld ist keine Null.
Wenn etwas nicht vergleichbar ist, vergleichen wir es nicht
Wir überprüfen auch, ob das Original unverändert erhalten bleibt, wenn eine Datei geöffnet und anschließend ohne Änderungen gespeichert wird.
mote prüft 652 CommonMark-Beispiele. Außerdem öffnen und speichern wir sämtliche Dokumente im Repository erneut und überprüfen anschließend, ob sie Byte für Byte identisch sind. Sobald auch nur eine Abweichung auftritt, betrachten wir das nicht als Leistungsproblem, sondern als Fehler mit Datenverlust.
Für konkurrierende Apps haben wir keine Ergebnisse angegeben. Der Grund dafür ist, dass sich der Speichervorgang nur schwer unter denselben Bedingungen automatisieren lässt.
Vor der Messung überprüfen wir außerdem den Zustand des Rechners. Wenn gerade kompiliert wird, beginnen wir die Messung nicht. Einen Browser beanstanden wir nur, wenn er tatsächlich viel CPU-Leistung beansprucht. Die durchschnittliche Systemlast, der CPU-Leerlaufanteil, die Entscheidungskriterien und die zum Messzeitpunkt ermittelten Werte werden sämtlich in den Ergebnissen festgehalten.
Diese Regel entstand aus einer schlechten Erfahrung.
Als wir die Startzeit bei geöffnetem Browser mit hoher CPU-Auslastung maßen, sah es so aus, als hätte sich die Leistung verschlechtert. Nachdem wir den vorherigen und den aktuellen Commit abwechselnd unter derselben Last gemessen hatten, stellte sich heraus, dass nicht eine Regression im Code, sondern die Auslastung des Rechners die Ursache war.
Seitdem beurteilen wir die Startzeit nicht mehr anhand eines einzigen absoluten Werts.
Wenn das Budget überschritten wird, ist kein Merge möglich
Das Leistungsbudget ist nicht bloß ein in der Dokumentation festgehaltenes Ziel. Es ist eine Vorgabe, die eingehalten werden muss, damit der Build erfolgreich ist.
Die Kriterien sind in hard und report unterteilt.
hard umfasst Punkte, deren Zahlen in einem Entscheidungsdokument festgelegt wurden. Sobald auch nur ein Wert den Grenzwert überschreitet, schlägt die Prüfung fehl. Eine gesonderte Ausnahmegenehmigung gibt es nicht.
report umfasst Punkte, für die es noch nicht genügend Belege gibt oder die stark von Einschränkungen der Plattform beeinflusst werden. Die Werte werden aufgezeichnet, blockieren den Build jedoch nicht.
Wenn ein Build aufgrund von Zahlen ohne ausreichende Grundlage blockiert wird, beginnen die Menschen, die Messung selbst zu vermeiden. Deshalb verwenden wir nur verlässliche Kriterien als Gate.
Die Messskripte, die ursprünglichen CSV-Dateien und die Ergebnis-JSON-Dateien werden gemeinsam im Repository aufbewahrt. Wenn dasselbe Skript unter denselben Bedingungen ausgeführt wird, lässt sich die Tabelle erneut erstellen. Wir bereiten außerdem die Veröffentlichung der Messwerkzeuge und Testdokumente in einem öffentlichen Benchmark-Repository vor.
Nur die guten Zahlen auszuwählen, ist keine Offenlegung.
Zu zeigen, was und wie gemessen wurde, unter welchen Bedingungen die Messung stattfand und was nicht gemessen werden konnte. So legt mote seine Zahlen offen.