Performance.
Si hay algo que todos los desarrolladores de software queremos, sobretodos los que trabajamos en la parte grafica, es buena performance. Mayor performance le permite al desarrollador dar mas características a un programa, le permite al usuario tener retroalimentación mas rápidamente sobre lo hizo con el software, y demás. Pero últimamente he estado mas pendiente sobre el error que muchos desarrolladores producen al momento de pensar en performance y de optimizar. Hay mucha gente que al momento de darse cuenta que tienen una problema de performance pregunta por ejemplo, si vale la pena hacer un expandir los bucles, si usar un array unidimensional seria mejor que uno bidimensional, o cosas de ese tipo. Y la respuesta real es, talvez. Pero en general, esos cambios no son los más importantes, y por otra parte uno no sabe si ese es en verdad el causante del problema de performance. El problema básicamente es que hay mucha gente tratando de resolver problemas de performance a ciegas. Si uno no sabe donde realmente esta el problema, cual es el causante del problema de performance va a ser muy difícil arreglar eso, o obtener buenas ganancias de performance. Yo lo que hago para optimizar es seguir seis pasos que en general me sirven muchísimo como para arreglar los problemas.
1. Vista preliminar del problema.
Lo primero que hay que hacer es hacer una vista preliminar del problema. ¿Cuál es el problema principal? ¿Cuanto más rápido tendría que ser el programa si no tuviera problemas de performance? Estas simples preguntas te permiten determinar bien que es lo que queres mejorar, te da las primeras ideas sobre cual es potencialmente le problema. Uno podría por ejemplo empezar a sospechar que la performance esta delimitada por el GPU, por el CPU, o lo que sea. Pero esto ya te da las primeras ideas.
2. Identificar los cuellos de botella.
Esto es una de las partes más importantes. Uno tiene que determinar cuales son los cuellos de botella. Lo que queremos hacer es mirar diferentes contadores de performance para determinar bien cuales son los puntos calientes donde se pierde la mayor parte del tiempo en el proceso. Por ejemplo, yo uso el Performance Analysis de Compuware DevPartner o el Intel VTune para ver los contadores generales. Mira el uso del CPU, el uso de memoria, y uso del disco (y dependiendo sobre lo que estas trabajando, puede ser bueno ver el uso del GPU o por ejemplo el uso del networking). Una vez que tenes estos números ya podes empezar a ver donde están los problemas principales. Hay que tener cuidado con las diferencias que hay entre la conclusión del paso uno y el paso dos. Cuando hay diferencias entre los dos es posible que te estés olvidando de algún factor muy importante por lo que puede ser necesario volver al paso uno y analizar mejor el tema.
3. Análisis de el/los cuellos de botella.
Acá se presenta un problema si no hiciste el paso uno y dos. Si no hiciste los pasos anteriores es muy probable empieces a analizar intensivamente algo que en verdad no es causante del cuello de botella. Uno puede esta sumamente concentrado sobre el uso del CPU cuando en verdad el problema esta en el uso del disco, el GPU, o lo que sea. Entonces para evitar perdidas de tiempo, hace los pasos uno y dos, son muy importantes. Ahora que ya sabes a que tenes que darle importancia es hora de hacer un análisis mas intensivo al cuello de botella. Ayudándote con las herramientas usadas anteriormente más un debugger uno ya puede empezar a detectar función por función y línea por línea adonde están los problemas más grandes.
4. Hipótesis y verificación de hipótesis.
En este punto uno ya tiene una buena idea sobre cual es la raíz de todo el problema. Pero para estar seguro lo mejor es hacer una hipótesis y verificar esa hipótesis. Por ejemplo si yo a esta altura me doy cuenta que me lector de shaders es muy lento yo podría hacer una hipótesis por ejemplo “Si yo en vez de tener 10 shaders tengo 100 con 1000 instrucciones cada uno entonces el problema tiene que ser mucho peor”. Entonces cuando verificas tu hipótesis podes ver si en verdad determinaste bien el problema o si tenes que volver al paso tres. Si no haces la verificación es posible que pierdas mucho tiempo en el futuro tratando de mejorar un cuello de botella que en verdad no existe.
5. Arreglar el cuello de botella
Acá esta el paso que generalmente la gente hace equivocadamente como primer y único paso al momento de intentar mejorar la performance. Uno puede perder mucho tiempo cambiando estructuras, expandiendo bucles y haciendo cosas así cuando en verdad uno podría determinar por el paso dos que, por ejemplo, en verdad el problema estaba en el tiempo de lectura en el disco. Pero si hiciste correctamente los pasos anteriores, en este momento podes encarar con bastante seguridad los problemas a resolver. Hace los cambios necesarios para mejorar la performance. Si podes hacerlo paso a paso y verificando cada paso es mejor para evitar romper todo.
6. Testear.
Ahora es momento de volver a sacar las herramientas que usaste en el paso dos y ver si en verdad arreglaste el cuello de botella. Si lo hiciste correctamente y ya no hay mas un cuello de botella, felicitaciones. Pero si no es así volve tantos pasos atrás como sea necesario, puede ser posible que tengas que volver al paso cinco o puede ser que tengas que volver al paso uno.
Esos fueron todos los pasos que yo seguí para por ejemplo obtener una ganancia del 20% en mi mesh loador. Acá esta el screenshot del antes y el después.
Antes.
Despues.
Espero que esto les sirva para usar mas efectivamente el tiempo, y para poder arreglar los problemas de performance lo mejor posible. Cualquier comentario no duden en usar el click en Comment.