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.
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:
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:
- É mais fácil de digitar do que 'bzip2';
- Compacta mais do que o bzip2;
- Usa os mesmos parâmetros que o bzip2 (
cat ... | xz -cv9 > dump.xzcontinua válido).
E você, tem algum exemplo assim? Comente!
