Se a tua shell demora mais de 100ms a arrancar, tens um problema de acumulação — não de performance. O Mijndert Stuij reduziu a zsh para ~30ms e explica como.

O artigo Life is too short for a slow terminal é daqueles textos que deviam ser leitura obrigatória para quem vive no terminal. O Mijndert descreve a optimização da shell dele ao longo de vários anos, e o resultado final é uma zsh que arranca em ~30ms. Nada de fork bombs, nada de esperas. Só uma shell que aparece quando se carrega no Enter.

A ideia central é simples: death by a thousand cuts. Cada plugin, cada fonte, cada lazy load mal feito soma milissegundos. Sozinhos são nada. Juntos, são segundos perdidos todos os dias. O Mijndert mostra como ser intencional com o que se adiciona à shell.


Pontos Principais

  • Sem frameworks — nada de oh-my-zsh, prezto ou gestores de plugins. Só 3 plugins sourced manualmente no .zshrc. O overhead de um framework é difícil de justificar quando só usas 3 coisas.
  • Caching de compinit — O compinit (autocomplete) só corre com a flag -C na maioria das vezes. Uma vez por dia faz o full run para regenerar o .zcompdump. Isto sozinho poupa dezenas de ms.
  • Lazy loading totalnvm, kubectl completions, e outros pesos-pesados só carregam quando são usados. A técnica é uma função stub que se substitui a si própria na primeira execução. Genial e simples.
  • Prompt assíncrono — usa o tema pure com suporte assíncrono. O git status não bloqueia o prompt. A shell aparece, e a info do git aparece quando estiver pronta.
  • Ghostty como terminal — GPU-accelerated, mínimo, nativo. O Ghostty é o terminal que o Mijndert usa, e a escolha não é inocente — um terminal lento anula uma shell rápida.
Como medir

Se nunca mediste o tempo de arranque da tua shell, este é o momento. O Mijndert recomenda várias abordagens:

# Métrica rápida
time zsh -i -c exit

# Benchmark mais sério com hyperfine
hyperfine 'zsh -i -c exit'

# Profiling detalhado
zprof  # no final do .zshrc

# Tracing com timestamps
zsh -i -c exit -xv 2>&1 | grep -E '^\+.*\.zsh' | head -20
Copy

O que mais gostei no artigo foi a abordagem cirúrgica. Não há atalhos mágicos — há medição, eliminação, lazy loading. E o resultado é uma shell que não se nota. E é esse o objectivo: uma ferramenta que não exige paciência.

Apliquei algumas das ideias ao meu setup. O caching do compinit foi o maior ganho imediato. O lazy loading do nvm também — não fazia sentido estar a carregar aquilo em todas as shells quando só uso Node em projectos específicos.

No fundo, o artigo é sobre uma filosofia que se aplica a muito mais que a shell: cada milissegundo conta. E num terminal, onde passamos horas por dia, 30ms vs 500ms faz uma diferença que se sente no ritmo de trabalho.

Link para o original

Comentários (0)

Nenhum comentário ainda. Seja o primeiro!

Deixar comentário