sysd.org
18jul/121

Terminal Velocity

 

Não, não se trata de um fenômeno físico, nem de um videogame, e muito menos de um filme com Charle Sheen. Já que passo a maior parte do dia na frente de um emulador de terminal (a famosa "tela preta com as letrinhas"),  observei que em alguns casos a user experience (se é que posso falar assim de CLI) é mais fluida e agradável do que em outros.

Em outras palavras, bandwidth de saída de caracteres na tela é bastante variável.

Isso é evidente em programas que subvertem a ideia do texto linear, os fabulosos TUI, tais como Vim ou Midnight Commander. Não é tão evidente em libcaca ou icat, pois são poucas as pessoas que sabem o que é isso e um número ainda menor encontra alguma utilidade para eles.

Felizmente, tendo reduzido "usabilidade" em "bandwidth", quantificar a métrica se torna fácil. É só pegar um texto grande, jogar na tela e cronometrar. "Texto grande", no caso do meu teste, foi o código-fonte do Perl v5.16.0, "colorificado" através de source-highlight:

find ~/perl-5.16.0 -type f -name '*.[cht]' -or -name '*.p[lm]' -exec \
    source-highlight --failsafe --infer-lang -f esc --style-file=esc.style -i {} \;

Depois, listei esse arquivo em cada emulador de terminal, dentro de VMs respectivos de cada OS (isso é, VM de Linux, de Windows e de Mac OS). VM fez-se necessário para "nivelar por baixo": seria injusto comparar VMs de Windows e Linux com o Mac OS nativo. Não mexi em configurações/preferências dos emuladores de terminal: fontes, cores e tamanho da tela são os default de cada "fabricante". O resultado está no gráfico no começo do post, e também nessa tabela:

Terminal Time (sec)
iTerm2.app (Mac) 12.72
Terminal.app (Mac) 41.03
xterm (Mac) 41.52
mintty (Win32) 14.86
xterm (Linux) 29.70
Gnome Terminal (Linux) 61.68
80x24 text-mode console (Linux) 276.68

O que salta aos olhos é que justamente o Linux, o sistema que contribuiu tanto para o "revival" do CLI, é o que tem emuladores de terminal mais lentos. E o terminal mais simples (aquele que no Linux é acessível via Ctrl+Alt+F1; a telona DOS clássica) é, contra-intuitivamente, o mais ineficiente!

É claro que esse benchmark é muito tosco. Talvez seria mais representativo utilizar a mesma fonte em todos os terminais testados, e também maximizar a tela dos mesmos (a quebra de linhas longas costuma ser custosa), além de desabilitar o histórico de scrollback. Fonte com/sem antialiasing e uso/não-uso de ANSI escape sequences também interferem na velocidade da saída. Mas, enfim: a diferença de velocidade é suficientemente grande e perceptível. Portanto, duvido muito que algum ajuste fino deixará Gnome Terminal mais rápido do que iTerm2.app.

21abr/120

Y is the new X

Segue aqui uma listinha de utilitários ligeiramente diferentes dos tradicionais e consolidados, mas cujas pequenas e grandes melhorias me fizeram renunciar quase que completamente os mais clássicos e abraçar os bleeding edge ;)

mosh is the new ssh

Não me entenda mal: SSH é muito mais do que uma simples shell remota! Também serve para tunelamento de conexões, transferência de arquivos, autenticação remota... Aliás, o próprio Mosh se autentica via SSH. Só que daí em diante, é outra história.

Mosh utiliza o protocolo UDP ao invés do TCP, então não precisa manter uma conexão. Simplificando muito, Mosh faz sincronização do estado do terminal remoto com o local, ao invés de redesenhar as telas caractere por caractere.

Ou seja: o seu link pode ser muito ruim, que o Mosh não está nem aí. Pode perder conexão, pode colocar o notebook em standby; quando o link voltar, está aí a sua shell, do jeito que você deixou! 'Network error: Connection reset by peer'‎, nunca mais.

Outro "efeito colateral" bacana do Mosh é que ele dispensa buffers. Já me ferrei dando um lsof numa conexão lerda; até que todo o output saia, SSH não deixa nem o input de Ctrl-C passar.

Para finalizar, o comparativo de tempo de resposta de SSH com Mosh, do site oficial do MIT:

tmux is the new screen

Mesmo que você seja um ávido fã do screen, o tmux vale uma espiada. O grande distintivo talvez seja o modelo client/server, que garante uma grande flexibilidade às sessões gerenciadas pelo tmux. Por exemplo, dá para mover janelas entre diversas sessões, ou então replicar o input em várias janelas (útil quando se quer iniciar o mesmo processo em diversos nós). Os atalhos de teclas tem perfis pré-definidos "emprestados" de Vim ou Emacs, e, é claro, dá para redefinir quase tudo do jeito que quiser pelo arquivo de configuração bastante legível. Ah, um bônus: split vertical da tela funciona sem patch adicional :)

Um breve tutorial:

  1. TMUX – The Terminal Multiplexer (Part 1)
  2. TMUX – The Terminal Multiplexer (Part 2)

htop is the new top

Esse dispensa apresentações. É praticamente um 'Activity Monitor.app' versão terminal. Infelizmente, a versão para MacOS tem algumas esquisitices (especialmente na parte que se refere à exibição da quantidade de memória). Ainda assim, é excelente para overview geral do sistema. Sempre mantenho um htop aberto nos meus servidores 😉

ack is the new grep

Descobri o ack recentemente. Não é bem um grep, mas sim uma combinação de find/grep específica para trabalhar com código-fonte. Em suma, ele faz busca recursiva utilizando regexp "sabor Perl", e desconsidera coisas como subdiretórios do Git ou SVN. Por exemplo uma versão (very) quick & dirty do Perl::PrereqScanner seria:

ack -ho --perl '^\s*use\s+[\w+\.:]+' | sort -u

xz is the new bzip2

Um pequeno devaneio: aparentemente, Inteligência Artificial e compressão de dados são assuntos afins. Os organizadores do Hutter Prize, por exemplo, acreditam que uma compressão eficiente de um texto natural seria de dificuldade equivalente a passar no teste de Turing.

Voltando ao tema original: anos atrás, quando clock de um PC high-end não passava de 1 GHz, e conexão broadband ainda estava engatinhando nos países do 3-o mundo, ver um código-fonte compactado com bzip2 numa página de download era de restaurar a fé na humanidade. Pois era evidentemente um ato altruístico por parte do disponibilizador levar muito mais tempo para compactar para poupar um pouquinho de tempo e banda de quem fizer o download.

Hoje, o bzip2 roda na velocidade do gzip de outrora. Eis que revive o algoritmo LZMA: muito mais voraz quanto à CPU/RAM, na grande maioria dos casos chuta bonito o traseiro do bzip2! O conheci através do 7-Zip, de longe o melhor compactador para Windows (xupem, WinZip e WinRAR!). Depois, para a minha alegria, descobri o xz, que:

  1. É mais fácil de digitar do que 'bzip2';
  2. Compacta mais do que o bzip2;
  3. Usa os mesmos parâmetros que o bzip2 (cat ... | xz -cv9 > dump.xz continua válido).

E você, tem algum exemplo assim? Comente!