Warum das Tippen auch bei langen Dokumenten nicht langsamer wird
Bei kurzen Notizen ist jeder Editor schnell. Der Unterschied zeigt sich, wenn das Dokument länger wird, und entscheidend ist, ob die Kosten eines einzelnen Tastendrucks mit der Größe der Bearbeitung oder mit der Größe des Dokuments wachsen.
Kurze Notizen lassen sich mit jedem Editor schnell schreiben. Der Unterschied zeigt sich, wenn das Dokument länger wird.
Wenn bei jedem Tastendruck das gesamte Dokument erneut gelesen und die Bildschirmdarstellung neu angeordnet wird, wird auch die Eingabe mit zunehmender Dokumentlänge langsamer. Deshalb wird ein Editor, der bei einer zehnzeiligen Notiz noch problemlos funktioniert, bei einem zweitausendzeiligen Entwurfsdokument mühsam.
mote betrachtete dieses Problem nicht als Leistungsproblem, das später behoben werden könnte. Es wurde von Anfang an als einzuhaltendes Gestaltungsprinzip festgelegt.
Beim Bearbeiten wird nur der geänderte Bereich erneut gelesen und angeordnet. Das gesamte Dokument wird nur beim Öffnen einer Datei erneut gelesen.
Nur geänderte Stellen werden erneut gelesen
In Markdown kann eine vorhergehende Zeile die Bedeutung nachfolgender Zeilen verändern. Wird weiter oben im Dokument ein Codeblock geöffnet, kann der gesamte darunterliegende Inhalt zu Code werden, und selbst derselbe Satz wird innerhalb einer Liste oder eines Zitats anders interpretiert.
Deshalb merkt sich mote „sichere Punkte“, an denen die Auswirkungen des vorausgehenden Inhalts mit Sicherheit enden. Bei einer Bearbeitung beginnt es am nächstgelegenen sicheren Punkt mit dem Lesen und hört auf, sobald der Inhalt wieder stabil ist.
Die darauf folgenden Blöcke werden nicht erneut gelesen. Wenn Zeilen hinzugekommen oder weggefallen sind, werden sie lediglich verschoben. So richten sich die Kosten nicht nach dem gesamten Dokument, sondern nach dem tatsächlich geänderten Bereich.
Der Parser folgt dem zeilenbasierten Algorithmus von CommonMark und besteht alle 652 Spezifikationstests. Doch bei inkrementeller Verarbeitung können sich unbemerkt leicht Fehler einschleichen. Deshalb werden auf zufällig erzeugte Dokumente 3.600 zufällige Bearbeitungen angewendet und das Ergebnis jedes Mal mit dem Ergebnis eines vollständigen erneuten Einlesens des Dokuments verglichen.
Diese Prüfung hat auch einen echten Fehler gefunden. Er trat auf, wenn der sichere Punkt und die bearbeitete Zeile exakt zusammenfielen.
Leistungsprinzipien werden durch Prüfungen abgesichert
Das Ziel sind p95 4 ms vom Tastendruck bis zum Abschluss der Kernverarbeitung. Wird diese Zeit überschritten, gilt das nicht als Verbesserungsaufgabe, sondern als Fehler.
Die Regeln wurden auch nicht nur dokumentiert. Automatische Prüfungen stellen sicher, dass ein vollständiges erneutes Parsen ausschließlich beim Öffnen einer Datei erfolgt. Sie verhindern außerdem Timer oder Frame-Aufgaben, die im Leerlauf wiederholt ausgeführt werden.
Auch die Leistung wird nicht nach Augenmaß beurteilt. Das Testsystem gibt Tasteneingaben auf dem tatsächlichen Bildschirm ein und misst die Verteilung der Verarbeitungszeiten. Statt des Mittelwerts oder Medians wird p95 betrachtet. Denn nicht die gewöhnliche Geschwindigkeit, sondern gelegentlich auftretende lange Verzögerungen frustrieren die Benutzer.
Für die Messung wird stets dasselbe festgelegte Dokument verwendet.
doc100k.md, geöffnet im Live-Modus. In der Statuszeile werden 96.513 Zeichen und eine Lesezeit von 103 Minuten angezeigt.Auch auf dem Bildschirm wird nur so viel wie nötig geändert
Es genügte nicht, nur den Parser auf inkrementelle Verarbeitung umzustellen.
Die Syntaxhervorhebung von Codeblöcken verarbeitete bei jeder Bearbeitung sämtliche Blöcke erneut. Das war die letzte Aufgabe, die unabhängig von der Größe der Bearbeitung mit zunehmender Dokumentlänge langsamer wurde.
Jetzt wird die Syntaxhervorhebung unveränderter Blöcke unverändert wiederverwendet. Blöcke hinter der Bearbeitungsstelle werden lediglich entsprechend der veränderten Zeilenzahl verschoben.
Blöcke außerhalb des sichtbaren Bereichs werden nicht angeordnet. Denn nur wenn sowohl der erneut gelesene als auch der erneut gezeichnete Bereich verkleinert wird, lässt sich die Geschwindigkeit auch bei langen Dokumenten halten.
Es gibt auch Ausnahmen
Manchmal muss das gesamte Dokument erneut verarbeitet werden.
Das ist beim Öffnen einer Datei oder bei einer Änderung des Zeilenumbruchformats der Fall. Wird eine Linkreferenzdefinition geändert, können sich Links an jeder beliebigen Stelle des Dokuments ändern, weshalb auch der Aktualisierungsbereich der Darstellung auf das gesamte Dokument erweitert wird.
Selbst wenn der Kern schnell ist, muss die Darstellung auf den nächsten Frame warten. Bei einem 60-Hz-Bildschirm wird der Frame-Abstand selbst zur Grenze. Deshalb werden die Verarbeitungszeit des Kerns und die Zeit bis zur tatsächlichen Darstellung auf dem Bildschirm getrennt gemessen und nicht auf dieselbe Achse gelegt. Deshalb unterscheiden sich die beiden Kurven auf dem Titelbild.
Ein schneller Editor ist kein Editor, der alles schnell erledigt.
Es ist ein Editor, der Arbeiten, die nicht erledigt werden müssen, gar nicht erst ausführt.