Ce que je me suis trompé à propos des terminaux rapides

• Une configuration de shell rapide ne s’obtient pas uniquement avec une configuration minimale, et les outils Zsh modernes améliorent autrement la vitesse de démarrage perçue
• time zsh -i -c exit mesure à la fois l’initialisation et la fermeture, mais ce que l’utilisateur attend réellement, c’est la première invite, l’exécution de la première commande et la latence à la saisie
• zsh-bench mesure des éléments réellement perceptibles comme le temps jusqu’à la première invite, le temps jusqu’à la première commande, la latence des commandes et la latence à la saisie
• Un gestionnaire de plugins n’est pas toujours lent, et antidote compile la liste des plugins en un unique script statique, sans résoudre les dépendances au démarrage
• Une configuration minimale n’est pas la seule voie vers la rapidité, mais un choix de simplicité compréhensible ; même un shell riche en fonctionnalités peut sembler instantané

---

Ce qui a été mal mesuré

• time zsh -i -c exit lance un shell interactif puis le ferme immédiatement, ce qui mesure à la fois le temps total d’initialisation et le temps de fermeture
• C’est un benchmark couramment utilisé, mais zsh-bench lui consacre une section séparée pour expliquer pourquoi cette méthode est erronée
• Ce que l’utilisateur attend réellement, ce n’est pas le temps d’initialisation complet, mais l’affichage de l’invite, l’exécution de la première commande et la latence de chaque frappe ensuite
• Certaines configurations peuvent paraître lentes dans ce benchmark tout en semblant plus rapides à l’usage réel
• zsh-bench mesure le temps jusqu’à la première invite, le temps jusqu’à l’exécution de la première commande, la latence des commandes et la latence à la saisie
• instant prompt affiche une invite mise en cache dès le lancement du shell et permet de saisir du texte avant même que .zshrc soit entièrement chargé
• Avec instant prompt, le coût d’initialisation importe beaucoup moins, car le temps de démarrage perçu devient presque nul, quelle que soit la durée réelle de fermeture, ce qui réduit l’importance de ce chiffre

Rectificatifs sur les gestionnaires de plugins et la coloration syntaxique

• La formule « les gestionnaires de plugins ajoutent de l’overhead » était trop générale

  • Certains gestionnaires de plugins ajoutent leur propre overhead au démarrage et résolvent les dépendances à chaque lancement
  • Mais attribuer cette caractéristique à toute la catégorie des gestionnaires de plugins était inexact
  • antidote compile une simple liste de plugins en un unique script statique, sans résolution de dépendances à l’ouverture du shell
  • L’approche d’antidote consiste à source un seul fichier généré, comme on le ferait avec des lignes source écrites à la main
  • Une distinction plus juste est de dire que les frameworks lourds qui réinterprètent les plugins à chaque démarrage sont lents, tandis que les gestionnaires modernes à bundling statique ne le sont pas
  • Les gestionnaires modernes à bundling statique fournissent aussi la gestion des mises à jour, alors qu’un script d’installation maison demande de gérer cela manuellement

• J’ai recommandé un surligneur syntaxique lent

  • Dans une configuration censée traiter la latence à la saisie, avoir source zsh-syntax-highlighting était, avec le recul, un choix embarrassant
  • zsh-syntax-highlighting recolore l’intégralité du buffer à chaque frappe, ce qui peut justement créer cette latence touche par touche sur les longues lignes de commande
  • Zsh-patina adopte une approche plus récente et peut offrir un meilleur ressenti que l’outil actuellement utilisé lorsqu’on saisit de longues commandes

• Le cœur de l’argument qui reste valable

  • Le fait de pouvoir lire l’intégralité du .zshrc d’un seul coup reste ce qui est réellement apprécié
  • L’essentiel est que le framework ne décide pas à votre place, et qu’il n’y ait pas de plugins non choisis
  • Comme il y a moins de composants, il est plus facile de repérer l’origine d’un ralentissement
  • Ce choix relève davantage d’une préférence pour la simplicité que d’une quête de vitesse en soi ; la rapidité qui en découle n’est qu’un effet secondaire
  • Un shell complet en fonctionnalités peut aussi être rapide et sembler instantané, et il existe plusieurs façons d’atteindre cet objectif
  • Si une configuration minimale est conservée, ce n’est pas parce qu’elle serait l’unique voie vers la rapidité, mais parce qu’on veut la comprendre

• Conclusion

  • L’article d’origine est conservé avec, en haut, une note pointant vers ce texte
  • La configuration est toujours disponible dans les dotfiles, et le surligneur syntaxique y est encore présent
  • Certaines parties de la configuration seront mises à jour pour utiliser des outils plus récents

[GN⁺]

Avis sur Lobste.rs

• Une bonne suite qui montre la force de la communauté et des échanges d’idées, et qui rend Internet un peu plus humain

• La première réaction, c’est l’étonnement de voir qu’il est possible d’admettre une erreur et de la corriger
  Plus sérieusement, je n’aime pas vraiment les nouveaux shells, donc j’avais passé le premier article, mais celui-ci m’a plu. ash n’a pas un comportement d’historique par défaut qui correspond à ma façon de l’utiliser, et des shells comme fish me donnent l’impression d’en faire trop avec des fonctionnalités d’interface qui ne m’intéressent pas
  En revanche, des fonctions qui ressemblent à du cache de prompt automatique ont l’air intéressantes. J’ai déjà bricolé moi-même un prompt monstrueux avec un cache bancal, donc ça me parle

• J’aime ce genre d’article. Si davantage de gens rendaient publiques leurs erreurs et les corrections qui suivent, Internet serait un endroit un peu plus humain

  • C’est l’auteur. Merci, et j’essaie justement de reconnaître régulièrement mes erreurs pour donner l’exemple à l’équipe

• Après avoir lu le premier article, j’ai déjà optimisé mon zshrc et réduit le temps de moitié. Ensuite, en creusant davantage, j’ai aussi utilisé zsh-bench, et cet article a servi de déclencheur d’optimisation

• Ce n’est plus maintenu, mais zsh4humans reste proche de l’état de l’art en matière de performances. La personne qui l’a créé ressemble à une sorte de génie de Zsh
  Je ne l’utilise pas moi-même, parce que je veux garder le contrôle. Cela dit, j’en ai repris certaines idées là où elles restent compréhensibles, comme le transient prompt
  Je ne savais pas non plus que zsh-bench était un projet du même auteur

  • Bon conseil. Il semble y avoir de vraies pépites dans le projet zsh4humans, donc je vais y jeter un œil

• Cet article m’a fait découvrir zsh-patina
  J’utilise zsh-fast-syntax-highlighting depuis des années, mais il va falloir que j’évalue aussi ce nouvel outil

• Je me demande si le fait que zsh-syntax-highlighting réapplique la coloration à tout le buffer à chaque frappe produit vraiment une latence perceptible
  Les éditeurs de code font au fond quelque chose de similaire, et j’y remarque très rarement de la latence. Comparée à un éditeur, même une commande “longue” sur une ligne de commande reste généralement courte, donc c’est surprenant que cela pose problème
  Cela dit, si la coloration syntaxique est bien plus complexe qu’on ne l’imagine, c’est peut-être possible

• J’ai appris beaucoup de nouvelles astuces avec cet article. Jusqu’ici, je me contentais surtout d’éviter que les données affichées dans le prompt ne viennent de backends lents
  Ici, on est sur une optimisation du prompt bien plus fine, et dans un flux quotidien où l’on ouvre un nombre incalculable de terminaux, ces petites améliorations finissent par avoir un gros impact