Comprendo que es una broma, pero la intención que lleva no me resulta nueva. Llevo viendo desde hace unos años en distintos foros y en algunas conversaciones en persona cómo algunas personas desprecian completamente esta cuestión. Pero no como me lo enseñaron a mí, que es bastante más complicado (saber cuándo, dónde, cómo y por qué gastar tiempo en optimizar), sino un rechazo frontal a la actividad en sí.

He visto desde fuera y desde dentro cómo se conseguía darle vidilla a sistemas que, después de costar muchos cientos de miles de euros, resultaban insufribles hasta el punto de que no se podía decir que funcionasen.

En algunos casos algo se ha hecho tremendamente mal y más que “optimización” habría que decir “despeorización”. Pero otras veces no había nada realmente reprochable, sólo un sistema que ha crecido más de lo previsto inicialmente.

Un ejemplo interesante es un añadido para el IDE de Delphi llamado Delphi Speedup. Lo han sacado gente externa a Delphi y consigue que el entorno arranque mucho más rápido que como viene de fábrica, reemplazando librerías del runtime con algoritmos más eficientes.

Estoy de acuerdo con la frase, en el sentido de que el proceso de optimización llevado a cabo por gente que no es experta, puede empeorar todavía más las cosas.

Efectivamente, Nico, hay ocasiones en que no hay nada realmente mal, solo que un sistema ha crecido demasiado. En esos casos es cuando está justificada la optimización. Por eso lo de “No optimices todavía”, para indicar que la optimización debe hacerse cuando realmente veamos que hay un problema.

——

Guti, yo estoy harto de ver sistemas de optimización de datos para colecciones de datos que tienen apenas 1000 registros y que se accede 10 veces en toda la ejecución del programa. Para optimizar eso (que es inoptimizable ya que hasta con una búsqueda lineal se hace en un instante) se complica innecesariamente con caches y código lleno de bugs.

precisamente cuando las colecciones son pequeñas la mejor optimización es utilziar tablas hash (disponibles en todos los lenguajes) que proporcionan un acceso inmediato (sin búsquedas) y aunque ocupen algo más en de memoria compensan por su rápido acceso

En general estoy de acuerdo con la frase y lo que comentáis, pero me gustaría añadir que no siempre es así. Seguramente en el 90% lo es, pero no en todos los casos. Steven Haines en su Pro Java EE 5 Performance Management and Optimization hace una apología muy acertada sobre “early performance testing” para sistemas que tienen unos SLAs importantes (por ejemplo esto es muy común en sistemas financieros con fuertes restricciones de trabajo en tiempo real).

Un SLA típico es por ejemplo es “Todas las llamadas al servicio de entrada de órdenes tienen que ser servidas en un segundo. La creación de una órden no debería llevar más de 250 milisegundos.” o algo tan simple como “El sistema de noticias para el nivel acordado de usuarios (1500) no debe superar los 5Mb de memoria.”

En estos casos es muy importante diseñar el sistema pensando en el rendimiento (arquitectos), pero también lo es el crearlo (desarrolladores) teniendo muy encuenta estos requisitos. De otro modo al final te puedes encontrar con situaciones como tener que migrar todo el modelo de datos (y como consecuencia tocar todo el sistema) porque resulta que el existente es demasiado pesado y hace fallar varios SLAs, o que uno de la partes del sistema se tiene que migrar a un sistema asíncrono porque no escala lo suficiente para cumplir los SLA.

En fin, el caso es que como se comenta en ese libro, no está de mal añadir en estos casos SLAs a los unit tests y a los integration tests. No se trata de cumplirlos desde el principio, pero si por ejemplo no cumplimos un SLA de memoria es importante que el test correspondiente esté fallando ya que de este modo siempre sabemos que hay algo que se debe optimizar y así el toro no nos pillará de repente a una semana de la entrega.

Juanjo, complicarse la vida innecesariamente puede venir por muchos otros caminos, por ejemplo el matrimonio. La excusa que ponga el perpretador puede coger mala fama inmerecidamente a base de repetirse, como le ocurre al noble arte de la optimización. A mí “arquitectura” me hace saltar las alarmas despupés de ver programas y más programas que tienen una fascinante arquitectura que consigue mágicamente que se tarde cinco veces más en programarlos, sin ninguna ganancia.

Me parece muy interesante lo que cuenta martin. Para estos lodos no hay mejor que medir, que por cierto es la primera regla de la optimización. Cuando mido casi invariablemente me doy cuenta de lo horriblemente equivocado que estaba sobre las causas de la lentitud de un programa.

Nico, entonces estamos de acuerdo. Medir primero, después, cuando se ve el problema, buscar el problema (que no es el que habíamos previsto, seguro) y optimizar.

Estas reglas son un corolario de otra aún más general:
Nunca resuelvas nada con ingenio que bien puedas resolver por fuerza bruta. Y si no, que se lo pregunten a los que construyeron las piramides, esos sí que dejaron la optimización para después ¡juas! :-D