7 de febrero de 2008

Optimización de sistemas (II)

En el caso de que la aplicación no tenga demasiada entrada/salida, o que esta ya esté muy afinada con cachés y demás, es probable que se pueda optimizar mucho.

Probablemente todas las funciones y métodos de tu aplicación puedan optimizarse, pero hacer eso llevaría muchísimo trabajo.

Hay una máxima en informática que se aplica a muchísimos campos: la del 80/20. En el caso de la optimización de sistemas, viene a ser algo así como: "el 80% del tiempo tu programa está ejecutando el 20% de las instrucciones del programa".

Ese 20% en el que el programa se tira el 80% del tiempo, es lo que se llama un cuello de botella. ¿Para qué te vas a molestar en optimizar el otro 80%, si con arreglar el cuello de botella mejoras el rendimiento general muchísimo?

Antes de empezar a optimizar un programa hay que tener claro hasta donde se quiere llegar. Siempre puedes conseguir que se ejecute un poco más rápido, pero va a llegar un momento que las ganancias que se consigan serán despreciables en comparación con el trabajo que lleva. Por eso es imprescindible tener unas metas de rendimiento, y limitarse a ellas.

En una aplicación de cálculos intensivos sobre tarificaciones de llamadas de móviles en la que trabajé, nuestro cliente ponía una serie de requisitos como "quiero retarificar mi cartera de clientes, de dos millones, en menos de una hora". El momento en que se consigue llegar a esa meta es el momento en el que se debe parar si no se quiere alargar siglos el desarrollo.

Además de unas metas claras, a la hora de optimizar es necesario tener claros cuales son los cuellos de botella para saber donde enfocar los esfuerzos. La intuición puede decirte donde están. Puntos con entrada / salida, funciones muy complejas, con mucho bucle y demás suelen ser las grandes candidatas a optimizar. Pero ¿para qué hipotetizar cuando hay herramientas que te lo pueden asegurar?

Estas herramientas son los 'profiler', y son tus mejores aliadas. Básicamente se dedican a llevar la cuenta de cuanto tiempo pasa tu programa por cada método/clase...., cuantas veces pasa, y cual es el porcentaje que supone esto sobre el total. Una vez que se saben esos datos, es fácil ir al punto más conflictivo, y solucionarlo, y repetir la ejecución hasta que se llegue a la meta que se había prefijado.

Continuará....

3 comentarios:

Tungusky dijo...

Entonces... se podría hacer que algo fuera mucho más rápido u "optimizarlo más" pero no se hace porque habría que dedicarle mucho tiempo, y dices que no merece la pena el esfuerzo para los resultados, vamos, que una vez pasado el cuello de botella olvidate...
Esto se puede aplicar a muchas otras cosas en la vida diaria!!
Saluditos!!

Tito HX dijo...

Lo de los profilers es una de las cosas, junto a LaTeX, que nos deberían enseñar a usar en la carrera. Si te dedicas a aplicaciones con mucha E/S con el usuario, no se nota mucho, pero cuando tienes que hacer una aplicación de tiempo real... mano de santo. el VTune me ha solucionado la papeleta alguna que otra vez.

De todas formas, es una buena idea programarse siempre una pequeña clase "cronómetro", o como quieras llamarla, y poner puntos de control. No es tan preciso como un profiler, pero a menudo es suficiente, y no tan engorroso. Donde curraba uno se preparó un sistema de estos, con gráficas por pantalla y demás, y ayudaba mucho.

Por cierto, a ver si haces una mención especial a los compiladores. Vale que un código mal estructurado o con cuellos de botella te jode vivo, pero una vez que detectas y eliminas esa parte, un buen compilador es lo mejor que puede haber. El de Intel es lento de narices compilando, pero luego se nota, y mucho.

Soy Gustavo. dijo...

Nunca lo había visto de esa manera, pero tienes razón Tungus! Lo ves como el friki-blog también es interesante? XDD

Qué alegría me ha dado verte por aquí, Tito! Pensaba hacer unos pocos artículos más con esa temática, sobre todo centrado en Java, pero lo de los compiladores no se me había ocurrido comentarlo :)