Wobei ich mich bei schnellen Terminals geirrt habe

• Eine schnelle Shell-Konfiguration wird nicht nur durch minimale Einstellungen erreicht; moderne Zsh-Tools verbessern die wahrgenommene Startgeschwindigkeit auf andere Weise
• time zsh -i -c exit misst sowohl Initialisierung als auch Beendigung, aber worauf Nutzer tatsächlich warten, sind der erste Prompt, die Ausführung des ersten Befehls und Eingabeverzögerungen
• zsh-bench misst tatsächlich wahrnehmbare Faktoren wie die Zeit bis zum ersten Prompt, die Zeit bis zur Ausführung des ersten Befehls, Befehlsverzögerung und Eingabeverzögerung
• Plugin-Manager sind nicht immer langsam; antidote kompiliert die Plugin-Liste zu einem einzigen statischen Skript und löst beim Start keine Abhängigkeiten auf
• Eine minimale Konfiguration ist nicht der einzige Weg zu hoher Geschwindigkeit, sondern eine Entscheidung für verständliche Einfachheit; auch eine funktionsreiche Shell kann sich sofortig anfühlen

---

Was falsch gemessen wurde

• time zsh -i -c exit startet eine interaktive Shell und beendet sie sofort wieder, wodurch die gesamte Initialisierungs- und Beendigungszeit zusammen gemessen wird
• Diese Methode ist ein häufig genutzter Benchmark, aber zsh-bench behandelt in einem eigenen Abschnitt, warum sie falsch ist
• Worauf Nutzer tatsächlich warten, ist nicht die gesamte Initialisierungszeit, sondern die Anzeige des Prompts, die Ausführung des ersten Befehls und die Verzögerung bei jeder weiteren Tasteneingabe
• Manche Konfigurationen können in diesem Benchmark langsam wirken, sich in der tatsächlichen Nutzung aber schneller anfühlen
• zsh-bench misst die Zeit bis zum ersten Prompt, die Zeit bis zur Ausführung des ersten Befehls, Befehlsverzögerung und Eingabeverzögerung
• instant prompt rendert beim Start der Shell sofort einen gecachten Prompt und erlaubt Eingaben schon vor Abschluss von .zshrc
• Mit instant prompt sinkt die wahrgenommene Startzeit unabhängig von den Initialisierungskosten auf nahezu 0, wodurch die Zahl für die Beendigungszeit an Bedeutung verliert

Korrekturen zu Plugin-Managern und Syntax-Highlighting

• Die Aussage „Plugin-Manager fügen Overhead hinzu“ war zu pauschal

  • Manche Plugin-Manager fügen beim Start eigenen Overhead und Abhängigkeitsauflösung hinzu
  • Diese Eigenschaft auf die gesamte Kategorie der Plugin-Manager zu übertragen, war jedoch ungenau
  • antidote kompiliert eine einfache Liste von Plugins zu einem einzigen statischen Skript und löst beim Öffnen der Shell keine Abhängigkeiten auf
  • Beim Ansatz von antidote wird genau eine generierte Datei gesourct, ähnlich wie bei selbst geschriebenen source-Zeilen
  • Die genauere Unterscheidung ist, dass schwere Frameworks, die Plugins bei jedem Start neu auflösen, langsam sind, moderne Manager mit statischem Bundling dagegen nicht
  • Moderne Manager mit statischem Bundling übernehmen außerdem die Update-Verwaltung, während selbst gebaute Installationsskripte das manuell erledigen

• Es wurde ein langsamer Syntax-Highlighter empfohlen

  • In einer Konfiguration, die sich mit Eingabeverzögerung befasst, zsh-syntax-highlighting zu sourcen, ist rückblickend eine peinliche Wahl
  • zsh-syntax-highlighting hebt bei jedem Tastendruck den gesamten Puffer erneut hervor und kann bei langen Befehlszeilen genau die eingabebezogene Verzögerung erzeugen
  • Zsh-patina ist ein neuerer Ansatz und kann sich beim Eingeben langer Befehle besser anfühlen als das derzeit verwendete Tool

• Der Kern der verbleibenden Aussage

  • Dass sich die gesamte .zshrc auf einmal lesen lässt, ist tatsächlich der bevorzugte Aspekt
  • Entscheidend ist, dass kein Framework die Entscheidungen übernimmt und es keine nicht selbst gewählten Plugins gibt
  • Weil es weniger Komponenten gibt, lassen sich langsame Stellen leichter finden
  • Diese Entscheidung ist eher eine Vorliebe für Einfachheit als für Geschwindigkeit selbst; dass Einfachheit zu höherer Geschwindigkeit führt, ist ein Nebeneffekt
  • Auch eine voll ausgestattete Shell kann schnell sein und sich unmittelbar anfühlen, und es gibt mehrere Wege, dieses Ziel zu erreichen
  • Eine minimale Konfiguration bleibt erhalten, nicht weil sie der einzige Weg zu hoher Geschwindigkeit ist, sondern weil sie verstanden werden soll

• Abschluss

  • Der ursprüngliche Beitrag bleibt mit einem Hinweis am Anfang erhalten, der auf diesen Text verweist
  • Die Konfiguration liegt weiterhin in den dotfiles, und auch der Syntax-Highlighter ist noch enthalten
  • Einige Einstellungen werden voraussichtlich aktualisiert, um modernere Tools zu verwenden

[GN⁺]

Lobste.rs-Kommentare

• Ein guter Folgebeitrag, der die Stärke von Community und Ideenaustausch zeigt und das Internet etwas menschlicher wirken lässt

• Zuerst kam die Reaktion auf, wie erstaunlich es sei, dass man Fehler eingestehen und korrigieren kann.
  Ernsthaft gesagt mag ich viele der neuen Shells nicht besonders, deshalb hatte ich den ersten Artikel übersprungen, aber dieser hier gefiel mir. ash passt mit seinem Standard-History-Verhalten nicht zu meiner Art der Nutzung, und Shells wie fish wirken auf mich mit UI-Features, die mich nicht interessieren, überladen.
  Allerdings sieht etwas wie automatisches Prompt-Caching ziemlich gut aus. Das spricht mich besonders an, weil ich selbst schon einmal ein monströses Prompt gebaut und ziemlich wacklig gecacht habe

• Solche Beiträge mag ich. Wenn mehr Menschen ihre Fehler und spätere Korrekturen öffentlich machen würden, wäre das Internet ein etwas menschlicherer Ort

  • Ich bin der Autor. Danke, und ich bemühe mich besonders darum, Fehler einzugestehen, um dem Team ein Vorbild zu sein

• Nach dem ersten Artikel hatte ich bereits mein zshrc optimiert und die Zeit halbiert. Danach habe ich weiter recherchiert und auch zsh-bench verwendet, und der Artikel war der Anstoß zur Optimierung

• Es wird zwar nicht mehr gepflegt, aber zsh4humans ist bei der Performance fast State of the Art. Die Person dahinter wirkt wie eine Art Zsh-Genie.
  Ich nutze es selbst nicht, weil ich die Kontrolle behalten möchte. Trotzdem habe ich in Bereichen, die ich nachvollziehen kann, Ideen wie den transient prompt übernommen.
  Mir war auch nicht klar, dass zsh-bench ein Projekt desselben Autors ist

  • Guter Hinweis. Es sieht so aus, als gäbe es im zsh4humans-Projekt echte Perlen, also werde ich es mir ansehen

• Durch diesen Artikel habe ich zsh-patina kennengelernt.
  Ich nutze seit einigen Jahren zsh-fast-syntax-highlighting, aber dieses neue Tool sollte ich mir auch ansehen

• Ich frage mich, ob es in der Praxis wirklich auffällt, dass zsh-syntax-highlighting bei jedem Tastendruck den ganzen Buffer erneut hervorhebt und dadurch Latenz erzeugt.
  Code-Editoren machen im Wesentlichen etwas Ähnliches, und dort bemerke ich fast nie Verzögerungen. Selbst „lange“ Befehle in der Kommandozeile sind im Vergleich zu Editoren meist kurz, daher überrascht es mich, dass daraus ein Problem entsteht.
  Wenn Syntax-Highlighting allerdings viel komplexer ist, als ich denke, könnte es natürlich daran liegen

• Aus diesem Artikel habe ich viele neue Kniffe gelernt. Bisher hatte ich nur einfache Anpassungen vorgenommen, etwa darauf zu achten, dass die Daten im Prompt nicht aus langsamen Backends kommen.
  Hier geht es um deutlich feinere Prompt-Optimierung, und in einem Arbeitsablauf, in dem man täglich unzählige Terminals öffnet, summieren sich solche kleinen Verbesserungen zu einer großen Wirkung