Software rápido e software bom: por que performance ainda importa

O que é software rápido

Software rápido não e apenas aquele que faz operações em milissegundos. E o software que responde antes que você perceba que pediu algo. E o editor que abre instantaneamente, o terminal que não hesita, o app que não te faz esperar por nada.

Craig Mod escreveu um ensaio em 2019 que ficou famoso na comunidade de desenvolvedores: Fast Software, the Best Software. A tese e simples e poderosa: software rápido passa uma mensagem de respeito. Ele diz que o criador se importou o suficiente para não desperdiçar o tempo de quem usa.

O ensaio ressurgiu em destaque no Hacker News em 2026 com dezenas de comentários de desenvolvedores reconhecendo o problema: a maioria dos softwares que usamos hoje esta ficando mais lento, não mais rápido, mesmo com hardware exponencialmente mais poderoso.

Como a lentidão se normalizou

Nos anos 90 e inicio dos anos 2000, software lento era um problema técnico solucionavel. O hardware era limitado e os programadores precisavam ser criativos para espremer performance de cada byte de memoria e ciclo de CPU.

Com o barateamento do hardware, mudou o incentivo. E mais fácil contratar um dev para adicionar uma feature do que pagar outro para otimizar o que já existe. O resultado: software que em 2010 rodava em uma máquina de 512MB de RAM hoje exige 4GB para fazer a mesma coisa.

A web piorou o problema. Bundlers, frameworks, analytics, trackers e ads de terceiros somam centenas de kilobytes de JavaScript em cada página. Uma noticia simples carrega mais código do que o Space Shuttle tinha de software.

Principais características de software rápido

Software genuinamente rápido tem algumas propriedades em comum:

• Startup instantâneo: abre antes de você notar que clicou. Ferramentas de linha de comando são o exemplo canónico.
• Resposta imediata ao input: cada tecla pressionada, cada clique, gera feedback visual em menos de 100ms.
• Operações em background: salvamento, sync, indexação acontecem sem bloquear a interface.
• Sem janelas de loading desnecessárias: dados aparecem progressivamente, não atrás de um spinner por 3 segundos.
• Memoria proporcional ao trabalho: não aloca gigabytes de RAM para ficar ocioso.

Ferramentas como Sublime Text, ripgrep, SQLite e Zed editor são frequentemente citadas como exemplos modernos de software que priorizou velocidade como feature central.

Como medir e melhorar: primeiros passos

Antes de otimizar, meca. Essa e a regra mais importante de performance:

time meu-programa --version
Python -m cProfile -s cumulative meu_script.py | head -20
npx lighthouse https://meusite.com.br --only-categories=performance --output=json

Para frontend web, o Core Web Vitals do Google define métricas objetivas: LCP (Largest Contentful Paint) abaixo de 2.5s, FID abaixo de 100ms, CLS abaixo de 0.1. São bons pontos de partida para qualquer projeto web.

Para apps desktop ou CLI, meca tempo de startup (cold e warm), tempo de resposta a input do usuário e pico de uso de memoria. Ferramentas como perf no Linux ou Instruments no Mac são essenciais.

Exemplo prático: antes e depois de uma otimização real

Considere uma API que busca dados de usuário e retorna um JSON. O problema N+1 de queries e um dos mais comuns:

# Versão lenta: N queries para N users
def get_users_with_orders(user_ids):
    result = []
    for uid in user_ids:
        user = db.query("SELECT * FROM users WHERE id = ?", uid)
        orders = db.query("SELECT * FROM orders WHERE user_id = ?", uid)
        result.append({**user, "orders": orders})
    return result

# Versão rápida: 2 queries no total
def get_users_with_orders(user_ids):
    users = db.query("SELECT * FROM users WHERE id IN (?)", user_ids)
    orders = db.query("SELECT * FROM orders WHERE user_id IN (?)", user_ids)
    orders_by_user = group_by(orders, key="user_id")
    return [{**u, "orders": orders_by_user.get(u["id"], [])} for u in users]

Com 100 usuários, a versão lenta faz 201 queries; a versão rápida faz 2. Em produção com carga real, essa diferença e a entre uma API que funciona e uma que cai.

Comparação: abordagens para melhorar performance

Existem diferentes estratégias dependendo do problema:

• Algoritmos e estruturas de dados: a otimização mais impactante. Um O(n log n) substitui um O(n2) e nenhum hardware compensa a diferença em escala.
• Caching: armazenar resultados de operações caras. Eficaz quando os dados mudam pouco e são acessados frequentemente.
• Lazy loading: carregar apenas o que é necessário agora. Fundamental em frontends e APIs com muitos dados.
• Paralelismo: usar múltiplos cores ou threads para operações independentes.
• Escolha de tecnologia: as vezes o problema e a stack. Go ou Rust podem ser 10-100x mais rápidos que Python para processamento intensivo.

Pontos positivos e limitações da obsessão com performance

Software rápido tem custos: geralmente exige mais esforço de desenvolvimento, código mais complexo e mais testes. O trade-off e real.

Premature optimization is still the root of all evil, como disse Donald Knuth. Otimizar antes de entender onde esta o gargalo desperdiça tempo e cria código mais difícil de manter.

Por outro lado, ignorar performance desde o inicio cria divida técnica que se paga com juros altos. Um sistema que nunca foi desenhado para ser rápido raramente se torna rápido depois sem reescrita significativa.

Casos de uso reais

SaaS B2B: em dashboards com muitos dados, a diferença entre carregar em 0.5s e 3s e a diferença entre uma ferramenta que a equipe ama e uma que evita. Performance e retenção.

E-commerce: estudos da Amazon e Google mostram que cada 100ms de latência adicional reduz conversão em 1%. Para lojas com volume significativo, performance e diretamente revenue.

CLI e ferramentas de desenvolvedor: ferramentas usadas centenas de vezes por dia precisam ser instantâneas. Um compilador que demora 30s vs 3s muda completamente o ciclo de desenvolvimento.

Apps mobile: em redes 3G ou dispositivos de entrada no mercado brasileiro, a diferença de performance e ainda mais crítica. Otimize para o dispositivo mediano dos seus usuários.

Dicas e boas práticas

Vale a pena priorizar performance?

Para software que pessoas usam repetidamente no dia a dia: sim, absolutamente. A diferença entre software rápido e lento e sentida a cada uso. Usuários não reclamam de software rápido.

Para um prototipo ou MVP inicial: menos urgente. Faca funcionar primeiro, depois faca funcionar rápido. Mas já pense em performance na arquitetura inicial para não criar armadilhas irrecuperáveis.

O próximo passo: instale o lighthouse no seu projeto atual e meca onde esta. Você provavelmente vai se surpreender com o que vai encontrar.