25. Estratégias de ajuste de código
Desempenho começa no projeto; meça antes de otimizar, porque o gargalo quase nunca está onde você pensa.
Resumo
- Desempenho é uma dimensão da qualidade. Antes de ajustar código: requisitos, projeto, algoritmos, compilador, hardware.
- Pareto: ~20% das rotinas consomem ~80% do tempo. Knuth: menos de 4% do programa > 50% do tempo.
- Mitos: menos linhas = mais rápido; "essa operação é mais rápida"; otimizar enquanto programa; rápido > correto.
- Jackson: "1. Não otimize. 2. (Só especialistas) Não otimize ainda", até ter solução clara e correta.
- Meça cada mudança; se não melhorar, desfaça. Lentidão comum: E/S, paginação, chamadas ao sistema.
Perguntas-chave
responda de cabeça, depois abraPor que não otimizar enquanto programa?
Porque não se sabe onde está o gargalo; o esforço vai para lugares irrelevantes e o código fica mais difícil, sem ganho medido.
Qual a abordagem recomendada de ajuste?
Programar com bom projeto, medir para achar pontos quentes, ajustar um por vez, medir cada ajuste e desfazer o que não ajudar.
Quais são fontes comuns de lentidão?
Entrada e saída (arquivos, rede, banco), paginação de memória, chamadas ao sistema operacional, linguagens interpretadas e erros.
Exercícios de fixação
0/5 respondidas1.
Um programador tem certeza de que a rotina X é o gargalo e passa uma semana otimizando-a. O que o livro diria?
2.
Qual afirmação o capítulo classifica como mito?
3.
Um ajuste de código foi aplicado e a medição mostra ganho de 0%. O que fazer?
4.
Um sistema lê o mesmo arquivo de configuração 1.000 vezes por requisição. Qual a provável fonte de lentidão?
5.
Segundo as regras de Jackson citadas no livro, quando otimizar?