Dominando Comandos Externos: Otimize o Desempenho de Scripts Bash

O script Bash mais rápido é frequentemente aquele que inicia menos programas.

Bash é bom para trabalho de cola: ler um arquivo, decidir o que fazer, iniciar outra ferramenta, verificar o status de saída e seguir em frente. Não é uma linguagem de processamento de dados de alto desempenho. A armadilha é usar Bash como se cada pequena operação de string precisasse de sed, cada comparação precisasse de expr e cada loop de arquivo precisasse de um novo grep. Esse estilo funciona em dez linhas. Torna-se doloroso em 200.000 linhas.

O custo é a inicialização do processo. Quando um script executa grep, sed, awk, cut, tr, date ou basename, o shell precisa criar outro processo e esperar por ele. Uma chamada não é um problema. Uma chamada dentro de um loop grande é um padrão que vale a pena corrigir.

Comece procurando por comandos dentro de loops:

grep -nE 'for |while ' script.sh
grep -nE 'grep|sed|awk|cut|tr|expr|basename|dirname|cat' script.sh

Isso não significa que toda correspondência seja ruim. Um único awk sobre um arquivo inteiro geralmente é aceitável. Um sed executado uma vez por linha é o tipo de coisa que transforma um script de manutenção em uma interrupção misteriosa durante uma implantação.

Substitua Pequenas Chamadas Externas pelo Próprio Bash

As vitórias mais fáceis são aritmética, comprimento de string, prefixos, sufixos e substituições simples. O Bash já sabe como fazer essas coisas.

Aritmética externa:

# Usa o utilitário externo 'expr'
RESULT=$(expr $A + $B)

Aritmética embutida:

RESULT=$((A + B))

Substituição externa de string:

MY_STRING="hello world"
NEW_STRING=$(echo "$MY_STRING" | sed 's/world/universe/')

Expansão de parâmetro:

MY_STRING="hello world"
NEW_STRING=${MY_STRING/world/universe}
printf '%s\n' "$NEW_STRING"

Tarefa	Método Ineficiente (Externo)	Método Eficiente (Embutido)
Extração de Substring	`echo "$STR"	cut -c 1-5`
Verificação de Comprimento	expr length "$STR"	${#STR}
Remover sufixo	basename "$file" .log	${file%.log}
Remover caminho	basename "$path"	${path##*/}
Remover nome do arquivo	dirname "$path"	${path%/*}
Substituir primeira correspondência	sed 's/foo/bar/'	${value/foo/bar}
Substituir todas as correspondências	sed 's/foo/bar/g'	${value//foo/bar}

Prefira [[ ... ]] para condicionais Bash. É uma palavra-chave do shell, lida com correspondência de padrões de forma limpa e evita algumas surpresas de citação que aparecem com [ ... ].

if [[ $name == *.log && -s $name ]]; then
  printf 'log não vazio: %s\n' "$name"
fi

Não force isso demais. A substituição de padrões do Bash não é um mecanismo regex completo. Se a regra for genuinamente complexa, uma passagem de awk ou perl é mais limpa e geralmente mais rápida do que uma expansão engenhosa do shell.

Trabalhe em Lote em Vez de Repetir o Trabalho

Se uma ferramenta pode processar muitas entradas em uma execução, alimente-a com muitas entradas. Isso é mais importante para grep, awk, sed, find, ferramentas de compressão, clientes de upload e qualquer coisa que se conecte a um serviço de rede.

Este loop inicia um grep por arquivo:

for file in *.log; do
  grep "ERROR" "$file" > "${file}.errors"
done

Se você precisa apenas de um resultado combinado, use um único grep:

grep "ERROR" *.log > all_errors.txt

Se você precisa de saída por arquivo, pense se a divisão é realmente necessária. Às vezes, a ferramenta downstream pode ler um prefixo de nome de arquivo de grep -H:

grep -H "ERROR" *.log > errors-with-filenames.txt

Para transformações orientadas a linhas, simplifique cadeias de grep | awk em um único programa awk:

awk '/data/ {print $1}' input.txt | sort > output.txt

Isso ainda executa sort, e tudo bem. Classificar é exatamente o tipo de trabalho que uma ferramenta externa deve fazer. A mudança útil é remover o cat inútil e o grep separado.

Leia Arquivos Sem cat

O loop padrão de leitura de linha é entediante por um motivo:

while IFS= read -r line; do
  printf 'Processando: %s\n' "$line"
done < file.txt

IFS= preserva espaços em branco iniciais e finais. -r impede que read trate barras invertidas como escapes. O redirecionamento mantém o loop no shell atual, o que importa se o loop atualiza variáveis que você precisa depois.

Esta versão parece inofensiva, mas geralmente é pior:

cat file.txt | while read -r line; do
  count=$((count + 1))
done
printf '%s\n' "$count"

No Bash, um segmento de pipe geralmente é executado em um subshell, então count pode não ser atualizado no shell pai. Também inicia cat sem benefício.

Use substituição de processo quando a entrada for realmente produzida por um comando:

while IFS= read -r file; do
  printf 'arquivo grande: %s\n' "$file"
done < <(find /var/log -type f -size +100M)

Aqui find está fazendo trabalho real. Manter o loop no shell atual ainda é útil.

Use find -exec ... + e xargs com Cuidado

Loops de arquivo são uma fonte comum de lentidão acidental:

for file in $(find . -name '*.tmp'); do
  rm "$file"
done

Isso quebra em espaços e inicia rm repetidamente. Use execução em lote:

find . -name '*.tmp' -exec rm -f {} +

A forma + passa muitos caminhos para cada invocação de rm. A forma mais antiga \; executa o comando uma vez por caminho.

Para comandos que se beneficiam de concorrência, xargs -P pode reduzir o tempo de relógio:

xargs -n 1 -P 4 curl -fsS -O < urls.txt

Use -0 quando nomes de arquivos estiverem envolvidos:

find uploads -type f -print0 | xargs -0 -n 50 -P 4 ./process-file

Paralelismo não é gratuito. Quatro trabalhos curl podem ser mais rápidos que um. Quarenta podem fazer você ser limitado por uma API ou saturar um host pequeno.

Meça Antes de Reescrever Tudo

A otimização certa depende de onde o tempo é gasto. Use temporização simples primeiro:

time ./script.sh

Para scripts pesados em processos, strace -c no Linux pode mostrar se o script está gastando tempo criando processos, abrindo arquivos ou esperando por E/S:

strace -f -c ./script.sh

O rastreamento do shell pode revelar comandos repetidos:

PS4='+ $SECONDS ${BASH_SOURCE}:${LINENO}: '
bash -x ./script.sh

Se o script gasta 95 por cento do tempo esperando por uma exportação de banco de dados, substituir ${value/foo/bar} não fará diferença. Se ele executa sed 300.000 vezes, fará.

Saiba Quando Ferramentas Externas São Melhores

Objetivo	Melhor Ferramenta (Geralmente)	Notas
Extração e filtragem de campos	awk	Melhor que loops Bash para texto tabular.
Edição de fluxo	sed	Bom para uma passagem sobre um arquivo.
Travessia de arquivos	find	Mais seguro que analisar ls.
JSON	jq	Não analise JSON com cut.
Trabalhos paralelos	xargs -P ou GNU parallel	Adicione limites e lide com falhas.
Processamento de texto grande	awk, perl, Python	Frequentemente mais claro que Bash heroico.

Os built-ins do Bash são rápidos, mas a manutenibilidade ainda vence. Prefiro manter um script awk claro do que 40 linhas de expansão de parâmetro frágil que apenas o autor original entende.

Uma Lista de Verificação Prática de Revisão

Quando um script Bash parece lento, percorra-o nesta ordem:

1. Encontre comandos externos dentro de loops.
2. Substitua operações simples de aritmética e string pela expansão do Bash.
3. Remova chamadas inúteis de cat.
4. Agrupe argumentos de arquivo com grep, awk, sed, find -exec ... + ou xargs.
5. Mantenha loops de leitura de linha no shell atual quando as variáveis precisarem sobreviver ao loop.
6. Meça novamente.

Você não precisa transformar todo script em um exercício de benchmark. As grandes vitórias geralmente vêm de alguns pontos óbvios: um comando por linha, um comando por arquivo ou um comando por item de API. Corrija esses, mantenha o script legível e pare quando o tempo de execução não for mais um problema.