O que eu entendi errado sobre terminais rápidos

• Uma configuração de shell rápida não é alcançada apenas com o mínimo de ajustes, e as ferramentas modernas de Zsh melhoram a velocidade de inicialização percebida de outras formas
• time zsh -i -c exit mede a inicialização e o encerramento juntos, mas o que o usuário realmente espera são o primeiro prompt, a execução do primeiro comando e a latência na digitação
• O zsh-bench mede itens realmente perceptíveis, como tempo até o primeiro prompt, tempo até a execução do primeiro comando, latência de comando e latência de entrada
• Gerenciadores de plugins nem sempre são lentos, e o antidote compila a lista de plugins em um único script estático, sem resolver dependências na inicialização
• Uma configuração mínima não é o único caminho para alta velocidade, mas sim uma escolha por simplicidade compreensível, e um shell completo também pode parecer imediato

---

O que foi medido de forma errada

• time zsh -i -c exit inicia um shell interativo e o encerra imediatamente, medindo juntos o tempo total de inicialização e o tempo de saída
• Esse método é um benchmark comum, mas o zsh-bench dedica uma seção separada a explicar por que ele está errado
• O que o usuário realmente espera não é o tempo total de inicialização, mas sim a exibição do prompt, a execução do primeiro comando e a latência de cada tecla depois disso
• Algumas configurações podem parecer lentas nesse benchmark e ainda assim parecer mais rápidas no uso real
• O zsh-bench mede o tempo até o primeiro prompt, o tempo até a execução do primeiro comando, a latência de comando e a latência de entrada
• O instant prompt renderiza um prompt em cache no momento em que o shell inicia e permite digitação mesmo antes de o .zshrc terminar
• Quando o instant prompt é aplicado, o tempo de inicialização percebido fica quase próximo de 0, independentemente do custo de inicialização, o que reduz a importância do número de tempo de saída

Correções sobre gerenciadores de plugins e destaque de sintaxe

• O alcance da frase “gerenciadores de plugins adicionam overhead” era amplo demais

  • Alguns gerenciadores de plugins adicionam seu próprio overhead e resolução de dependências na inicialização
  • Porém, aplicar essa característica à categoria inteira de gerenciadores de plugins foi impreciso
  • O antidote compila uma lista simples de plugins em um único script estático e não resolve dependências ao abrir o shell
  • A abordagem do antidote consiste em dar source em um único arquivo gerado, como linhas source escritas manualmente
  • Uma distinção mais precisa é que frameworks pesados que resolvem plugins a cada inicialização são lentos, enquanto gerenciadores modernos com empacotamento estático não são
  • Gerenciadores modernos com empacotamento estático também oferecem gerenciamento de atualizações, enquanto scripts de instalação feitos à mão exigem isso manualmente

• Foi recomendado um realçador de sintaxe lento

  • Em uma configuração voltada a latência de entrada, ter incluído source de zsh-syntax-highlighting foi, olhando agora, uma escolha constrangedora
  • O zsh-syntax-highlighting reaplica destaque ao buffer inteiro a cada tecla pressionada e, em linhas de comando longas, pode justamente causar essa latência por tecla
  • O Zsh-patina é uma abordagem mais nova e, para quem digita comandos longos, pode oferecer uma sensação melhor do que a ferramenta usada atualmente

• O núcleo da tese que permanece

  • O fato de ser possível ler todo o .zshrc de uma vez é a parte que realmente é preferida
  • O ponto principal é que o framework não decide no seu lugar, e não existem plugins que você não escolheu
  • Como há menos componentes, fica mais fácil encontrar trechos lentos quando eles aparecem
  • Essa escolha é uma preferência por simplicidade mais do que por velocidade em si, e a simplicidade levar a mais velocidade é um efeito colateral
  • Um shell completo também pode ser rápido e parecer imediato, e existem várias formas de chegar a esse objetivo
  • A configuração mínima é mantida não por ser o único caminho para alta velocidade, mas porque há o desejo de entendê-la

• Encerramento

  • O texto original continua no ar com uma nota no topo apontando para este texto
  • A configuração ainda está nos dotfiles, e o realçador de sintaxe também permanece lá
  • Algumas partes da configuração devem ser atualizadas para usar ferramentas mais modernas

[GN⁺]

Comentários do Lobste.rs

• Um bom texto de acompanhamento que mostra a força da comunidade e da troca de ideias, e faz a internet parecer um pouco mais humana

• A primeira reação foi de surpresa por ser possível admitir erros e corrigi-los
  Falando sério, eu não gosto muito de vários shells novos, então passei batido pelo primeiro texto, mas gostei deste. O comportamento padrão do histórico no ash não combina com a forma como eu uso, e shells como o fish me parecem exagerados em recursos de UI que não me interessam
  Ainda assim, funcionalidades como o que parece ser cache de prompt automático parecem boas. Isso me toca mais porque eu mesmo já fiz um prompt monstruoso e tentei armazená-lo em cache de forma meio improvisada

• Gosto desse tipo de texto. Se mais gente publicasse seus erros e correções posteriores, a internet seria um lugar um pouco mais humano

  • Sou o autor. Obrigado, e tento admitir erros com frequência, especialmente para dar exemplo ao time

• Depois de ver o primeiro texto, já otimizei meu zshrc e cortei o tempo pela metade. Depois continuei pesquisando e usei zsh-bench também, e aquele texto acabou servindo de gatilho para otimização

• Embora não seja mais mantido, zsh4humans continua perto do estado da arte em desempenho. A pessoa que fez isso parece ser uma espécie de gênio do Zsh
  Eu não uso diretamente porque quero manter o controle. Mesmo assim, peguei ideias como transient prompt nas partes que consigo entender
  Eu não sabia que zsh-bench também era um projeto do mesmo autor

  • Boa dica. Parece haver partes realmente brilhantes no projeto zsh4humans, então vou dar uma olhada

• Foi por causa deste texto que conheci o zsh-patina
  Uso o zsh-fast-syntax-highlighting há anos, mas vou ter que avaliar essa ferramenta nova também

• Fiquei curioso se essa parte sobre zsh-syntax-highlighting voltar a destacar o buffer inteiro a cada tecla realmente é perceptível na prática como fonte de latência
  Editores de código fazem algo essencialmente parecido, e quase nunca senti latência neles. Pela perspectiva de um editor, até comandos “longos” na linha de comando costumam ser curtos, então é surpreendente que isso vire um problema
  Mas, se o realce de sintaxe for muito mais complexo do que eu imagino, talvez faça sentido

• Aprendi várias dicas novas com este texto. Até agora eu só fazia ajustes simples, como evitar que os dados do prompt viessem de backends lentos
  Aqui há uma otimização de prompt bem mais minuciosa, e num fluxo diário em que se abre um número incontável de terminais, essas pequenas melhorias se acumulam e têm um grande impacto