En una revisión de código, probablemente hayas oído alguna vez que «la optimización prematura es la raíz de todos los males».
Pero al buscar y leer el original, la historia cambia un poco. Donald Knuth no quiso decir «no optimices» en absoluto.
Empecemos por la conclusión: Knuth dijo que había que «olvidar el 97% de las pequeñas eficiencias, pero no perder nunca las oportunidades de ese 3% crítico». La frase a medias que suele citarse omite por completo esta segunda parte.
Hoy repasaremos el contexto real de esta frase y cuándo conviene optimizar el código.
Así era realmente el original
La frase procede de un artículo que Donald Knuth escribió en 1974. Se titula «Structured Programming with go to Statements» y se publicó en ACM Computing Surveys.
Este es el texto original.
«Debemos olvidar las pequeñas eficiencias, aproximadamente el 97% del tiempo. La optimización prematura es la raíz de todos los males. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese 3% crítico.»
¿Lo ves? La frase que conocemos es solo el fragmento central.
Antes aparece «olvida el 97%» y después «no pierdas el 3%». Las tres frases forman un conjunto.
Knuth no dijo que no hubiera que optimizar. Dijo que había que elegir dónde concentrar el esfuerzo.
«Olvida el 97% y céntrate en el 3%»: esa es la clave
Knuth señaló algo más en el mismo artículo.
Los programadores desperdician muchísimo tiempo preocupándose por la velocidad de partes del programa que ni siquiera son importantes.
Además, esas optimizaciones anticipadas pueden dificultar la depuración y el mantenimiento.
El problema no es la optimización en sí, sino el momento y el lugar. El error está en modificar cualquier parte sin saber todavía dónde está el cuello de botella.
No significa que no debas optimizar, sino que no debes optimizar sin pruebas y en cualquier sitio.
Entonces, ¿cuándo hay que optimizar?
Es la pregunta más frecuente. La respuesta es sencilla: después de medir.
El 3% crítico de Knuth se encuentra midiendo, no por intuición. Ejecuta un perfilador, localiza dónde se consume realmente el tiempo y trabaja ahí.
Con Swift, puedes empezar comprobando el cuello de botella así.
// Mide qué código consume realmente el tiempo
let clock = ContinuousClock()
let elapsed = clock.measure {
slowFunction()
}
print(elapsed) // La sección que más tiempo consume es esa '3%'
Las mediciones suelen demostrar que nuestras expectativas eran erróneas. El lugar que creías lento funciona bien, mientras que un bucle que ni habías considerado consume todo el tiempo.
Esta distinción ayuda a separar la optimización prematura de la justificada.
| Categoría | Optimización prematura | Optimización justificada |
|---|---|---|
| Momento | Antes de medir, por intuición | Después de medir, con datos |
| Objetivo | Cualquier lugar llamativo | El 3% confirmado como cuello de botella |
| Resultado | El código solo se vuelve más complejo | Mejora real del rendimiento |
Una cosa más: quizá esta frase ni siquiera sea de Knuth
Hay una historia posterior interesante.
La frase también se atribuye a menudo a Tony Hoare (C. A. R. Hoare). Incluso sitios de citas populares la presentan como una frase de Hoare.
Sin embargo, el propio Knuth la llamó «Hoare’s Dictum» en su artículo de 1989, «The Errors of TeX».
Hoare, por su parte, dijo que no era una frase suya, sino de Knuth.
Los dos maestros se devolvieron la atribución mutuamente, pero según la evidencia documental, la opinión aceptada es que se trata de una expresión de Knuth que apareció por primera vez en el artículo de 1974.
Quién la pronunció primero es secundario; lo importante es que su significado original se ha recortado y malinterpretado.
Preguntas frecuentes
P. Entonces, ¿no tengo que preocuparme por el rendimiento desde el principio?
No. Las decisiones que determinan la estructura, como elegir un algoritmo, deben considerarse desde el principio. Knuth dijo que olvidáramos las eficiencias «insignificantes», no las decisiones de diseño.
P. ¿Cuándo hay que medir?
Después de crear código funcional. Primero haz que funcione; si es lento, usa un perfilador para localizar el cuello de botella y corrige solo esa parte.
Cuando vuelvas a encontrarte con esta frase, recuerda también el final: olvida el 97%, pero no pierdas el 3%.
Desconfía de optimizar sin medir, pero no retrocedas ante un cuello de botella real. Eso era lo que Knuth quería decir.
Si hoy hay una parte del código que ibas a modificar porque «parece lenta», prueba primero a ejecutar el perfilador.