Práticas Recomendadas de Desempenho
Regras de desempenho que evitam a otimização prematura e focam o esforço em gargalos medidos.
Como Usar Esta Lista
- Posição padrão: legibilidade sobre micro-otimização
- Quebre estas regras apenas com dados de perfil provando o ponto crítico (hotspot)
- Documente cada otimização com números antes e depois
A - Medição
- Perfilar antes de otimizar. cProfile, py-spy ou APM - nunca adivinhe.
- Definir SLA antes de ajustar. Conheça a latência p95 ou a taxa de transferência alvo.
- Benchmarking de cargas de trabalho realistas. Tamanhos de dados de produção e concorrência.
- Registrar números antes e depois. Cada otimização precisa de prova.
B - Algoritmo e Dados
- Algoritmo certo primeiro. O(n log n) supera O(n^2) micro-otimizado.
- Vetorializar loops numéricos. NumPy/Polars para operações de array e DataFrame.
- Transmitir (stream) grandes volumes de dados. Geradores em vez de listas materializadas.
- Estrutura de dados correta.
setpara pertinência,dequepara filas,dictpara consulta.
C - Concorrência
- asyncio para I/O-bound. httpx, asyncpg, aiofiles.
- multiprocessing para CPU-bound. Não threads (GIL).
- Limitar a concorrência. Semáforos e limites de pool evitam sobrecarga.
- Não bloquear em manipuladores async.
asyncio.to_threadpara código bloqueante legado.
D - Cache e I/O
- Cache com limites.
maxsizeeTTLem cada cache. - Pool de conexões. Reutilizar conexões de banco de dados e HTTP.
- Agrupar operações de I/O. Inserções em massa (bulk inserts), coletar requisições HTTP.
- Serialização eficiente. orjson para caminhos JSON críticos.
E - Quando Parar
- SLA atingido? Pare de otimizar. Trabalho adicional tem retornos decrescentes.
- Legibilidade preservada. Otimização complexa precisa de comentários explicando o porquê.
- Testes ainda passam. Correção antes da velocidade.
- Sem Cython/Rust prematuro. Python é rápido o suficiente até que o perfil indique o contrário.
FAQs
Python é lento?
Python é rápido o suficiente para a maioria das cargas de trabalho web e de dados. Otimize os pontos críticos, não a linguagem.
Devo usar PyPy?
Apenas se os benchmarks em sua carga de trabalho específica mostrarem ganhos claros.
List comprehension ou map?
Legibilidade em primeiro lugar. Perfilar se for crítico. As diferenças são geralmente negligenciáveis.
Quando usar Cython?
Quando um ponto crítico perfilado não pode ser corrigido com NumPy, algoritmos melhores ou cache.
Como prevenir regressão de desempenho?
Benchmarking dos caminhos críticos em CI com pytest-benchmark. Alerta em caso de violação de limite.
asyncio em todo lugar?
Não. Apenas serviços I/O-bound que se beneficiam da concorrência. Adiciona complexidade.
E o desempenho do banco de dados?
Índices, planos de consulta e eliminação de N+1 muitas vezes superam o ajuste no nível do aplicativo.
Devo usar __slots__?
Para milhões de objetos pequenos com atributos fixos. Não por padrão.
Como definir orçamentos de desempenho?
Definir latência p95 por endpoint. Bloquear implantações que excedem o orçamento em testes de carga.
Micro-otimizar concatenação de strings?
Apenas em loops críticos perfilados. f-strings são boas para código normal.
Relacionados
- Noções Básicas de Desempenho - começando
- Checklist de Auditoria de Desempenho - revisão sistemática
- cProfile e Profilers - encontrando pontos críticos
- Async e Concorrência para Taxa de Transferência - paralelismo
Versões de Stack: Esta página foi escrita para Python 3.14.0, FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+ e uv 0.6+.