La optimización es un tema muy importante en un proyecto. En
algunos más que en otros dada su propia idiosincrasia y el escenario de
producción en el que se van a desenvolver, ya que no es interesante invertir
esfuerzo en optimizar algo que ya funciona bien, no hay que llevar al extremo
el hecho de que todo se puede optimizar, pero obviamente siempre es un tema importante.
Se puede (y se debe) tener la optimización en mente desde
las fases más tempranas, sobre todo si está claro que el proyecto va a requerir
estar bien afinado para dar los resultados esperados.
Sin embargo, es interesante recordar que lo importante es que
los equipos de desarrollo pongan el esfuerzo en el lugar adecuado en el momento
adecuado. No es eficiente pretender mejorar cada bucle del código para arañar
unos milisegundos, cuando por otro lado pueden estar ejecutándose 20
procedimientos almacenados para recuperar datos, siendo la mayoría innecesarios
en ese momento.
En paralelismo de computadoras es conocida la Ley de Amdahl,
que como dice Wikipedia:
“…se usa para averiguar la mejora máxima de un sistema
cuando solo una parte de éste es mejorado.”
Esta ley es igual de útil en paralelismo que para la
optimización de aplicaciones en general, ya que prácticamente siempre hay un único
agujero negro de rendimiento que, una vez optimizado, mejora el resultado final
dramáticamente y hace desaparecer el problema que existía.
Teniendo esto en cuenta, lo importante a la hora de afrontar
la optimización de una aplicación, subsistema, caso de uso, pantalla,
funcionalidad, etc. es descubrir cuál es ese agujero negro responsable
principal de la caída del rendimiento y optimizarlo. No intentar optimizar a
ciegas. Para esto podemos ayudarnos de herramientas útiles como profilers, si
las trazas y pruebas sobre el código no son suficientes para revelar dónde se
encuentra el problema principal.
Para ilustrar lo anterior con un ejemplo clásico: imaginemos
un caso de uso en el que el tiempo de ejecución dedicado a la lógica de negocio
consume un 15% del total, el 10% se dedica a carga de controles e interfaz
gráfica y el 75% restante nos encontramos esperando por la carga de datos desde
la base de datos.
En este escenario resulta fácil ver como no es eficiente
intentar optimizar la lógica de negocio, ni la interfaz de usuario, sino
averiguar qué falla en la recuperación de datos: ¿puede ser código ADO.NET muy
ineficiente? ¿Puede ser que estemos recuperando datos que no se necesitan en su
totalidad en este caso de uso? ¿Puede ser que inspeccionando el plan de
ejecución del procedimiento almacenado que se invoca veamos que hace cosas innecesarias
o que podrían mejorarse bastante mediante mejor código T-SQL?
La buena práctica para plantear la optimización, por tanto, consiste
en averiguar dónde está el performance penalty y optimizarlo, no en dedicar esfuerzos a otras partes cuyo
impacto en el cómputo total es sólo el 10% ó 15%, porque optimizando esto la
mejora será casi imperceptible, el problema está en el 75%.
Creo que la optimización se debe realizar siempre que finalicemos un desarrollo, habituarse a optimizar el código, no solo con el fin de hacerlo mas rápido si no de eliminar líneas de código innecesarias, encapsular funciones y controles que van a ser reutilizados, utilizar using y dispose, etc, son prácticas que siempre deberíamos realizar.
Si hacemos esto nos habituamos a escribir mejor nuestro código. En cualquier caso es algo complicado, hace poco descubrí que el proceso un proceso de cacheo que utilizamos no era necesario, es mas provocaba todo lo contrario, habituarse a evaluar antes de optimizar es necesario.
Normalmente cuando leo código escrito meses atrás, muchas veces observo que se puede optimizar mas, en mi caso me pasaría el dia optimizando.
Saludos
Totalmente de acuerdo Juan, esa optimización a nivel de código a la que te refieres es la refactorización y es una muy buena práctica.
Lo ideal es que el código más «tosco», orientado primordialmente a satisfacer las funcionalidades en el inicio de un proyecto, se vaya refactorizando continuamente hasta converger en un código bien refactorizado al final.
Saludos.
Es cuando menos utópico que en los tiempos que corren aún se hable del coste «computacional» de los algoritmos y código que escribirmos.
En mi opinión, creo que no exagero al decir que el coste de cómputo es despreciable frente:
– A las técnicas de diseño, que nos «obligan a gastar» ciclos de CPU en pro de un código más limpio y estructurado.
– Al coste de las comunicaciones.
Y es en éste último donde se libran las verdaderas batallas, ahora más que nunca, con el desarrollo de las tecnologías en red (web 1.0, web 2.0, extranets e intranets, SaaS…) y los augurios por partes de fabricantes y otros interesados del colapso de la Red.