Em uma revisão de código, você provavelmente já ouviu alguém dizer que “a otimização prematura é a raiz de todos os males”.
Mas, quando você procura e lê o original, a história muda um pouco. Donald Knuth definitivamente não quis dizer “não otimize”.
Vamos começar pela conclusão: Knuth disse para “esquecer os 97% das pequenas eficiências, mas nunca deixar passar as oportunidades naquele 3% crítico”. A meia frase citada com frequência omite completamente essa parte final.
Hoje, vamos revisar o contexto real dessa frase e quando otimizar o código.
Este era o verdadeiro texto original
A frase vem de um artigo escrito por Donald Knuth em 1974. O título é “Structured Programming with go to Statements”, publicado na ACM Computing Surveys.
O texto original é o seguinte.
“Devemos esquecer as pequenas eficiências, digamos, em cerca de 97% do tempo. A otimização prematura é a raiz de todos os males. Ainda assim, não devemos perder nossas oportunidades naquele 3% crítico.”
Percebeu? A frase que conhecemos é apenas o trecho do meio.
Antes vem “esqueça os 97%” e depois “não perca os 3%”. As três frases formam um conjunto.
Knuth não disse para não otimizar. Ele disse para escolher onde concentrar o esforço.
“Esqueça os 97% e foque nos 3%”: esse é o ponto central
Knuth fez outra observação relacionada no mesmo artigo.
Programadores desperdiçam uma enorme quantidade de tempo se preocupando com a velocidade de partes do programa que não são importantes.
Além disso, otimizações feitas antecipadamente podem dificultar a depuração e a manutenção.
O problema não é a otimização em si, mas o momento e o lugar. O problema surge quando você altera qualquer parte sem saber onde está o gargalo.
Não significa “nunca otimize”, mas “não otimize sem evidências e em qualquer lugar”.
Então, quando devemos otimizar?
Essa é a pergunta mais comum. A resposta é simples: depois de medir.
O 3% crítico de Knuth é encontrado por medição, não por intuição. Execute um profiler, encontre o ponto que realmente consome tempo e trabalhe nele.
Com Swift, você pode começar verificando o gargalo assim.
// Meça qual código realmente está consumindo tempo
let clock = ContinuousClock()
let elapsed = clock.measure {
slowFunction()
}
print(elapsed) // O trecho que leva mais tempo é esse '3%'
As medições geralmente mostram que nossas expectativas estavam erradas. O lugar que você imaginava ser lento está normal, enquanto um loop que nem havia considerado consome todo o tempo.
Esta distinção facilita separar a otimização prematura da justificada.
| Categoria | Otimização prematura | Otimização justificada |
|---|---|---|
| Momento | Antes de medir, por intuição | Depois de medir, com dados |
| Alvo | Qualquer ponto chamativo | Os 3% confirmados como gargalo |
| Resultado | O código fica apenas mais complexo | Melhoria real de desempenho |
Mais uma coisa: talvez essa frase nem seja de Knuth
Existe uma história posterior interessante.
A frase também é frequentemente atribuída a Tony Hoare (C. A. R. Hoare). Até sites populares de citações a apresentam como uma frase de Hoare.
No entanto, o próprio Knuth a chamou de “Hoare’s Dictum” em seu artigo de 1989, “The Errors of TeX”.
Hoare, por sua vez, disse que a frase não era dele, mas de Knuth.
Os dois mestres atribuíram a frase um ao outro, mas, com base nas evidências documentais, o entendimento aceito é que se trata de uma expressão de Knuth, que apareceu primeiro no artigo de 1974.
Independentemente de quem a disse primeiro, o importante é que seu significado original foi reduzido pela metade e mal interpretado.
Perguntas frequentes
P. Então não preciso me preocupar com desempenho desde o início?
Não. Decisões que determinam a estrutura, como a escolha do algoritmo, precisam ser consideradas desde o início. Knuth disse para esquecer eficiências “pequenas”, não decisões de design.
P. Quando devo medir?
Depois de criar código funcional. Primeiro faça funcionar; se estiver lento, use um profiler para encontrar o gargalo e corrija apenas esse ponto.
Quando encontrar essa frase novamente, lembre-se também do final: esqueça os 97%, mas não perca os 3%.
Desconfie de otimizações sem medição, mas não recue diante de um gargalo real. Era isso que Knuth realmente queria dizer.
Se hoje existe algum trecho de código que você pretendia alterar porque “parece lento”, execute o profiler antes.