Diseño y Evaluación de Configuraciones – Práctica 3

Uso de un profiler

Situándonos…

Para esta práctica decidí emplear el profiler gprof en un entorno GNU/Linux sobre una aplicación desarrollada con las bibliotecas Qt para la asignatura Nuevas Tecnologías de la Programación. No obstante, la aplicación no era lo suficientemente pesada como para que gprof produjera resultados relevantes, con lo cual pasé a emplear otra práctica para la misma asignatura desarrollada en Java y hacer uso del plugin Profiler para Netbeans, también sobre GNU/Linux.

Instalación y uso.

La herramienta puede descargarse desde el menú de “Tools”/”Plugins” y buscando por “profile”. Una vez instalada se nos añadirán algunos elementos a la interfaz de Netbeans. Además de permitirnos medir el comportamiento de la aplicación, permite guardar los análisis y realizar comparaciones, de modo que nos facilita ver si una versión modificada de una aplicación es mejor que otra.

Cuando vayamos a realizar por primera vez el perfil, nos pedirá que realicemos una prueba de calibración del sistema y que integremos la información del perfil con nuestro proyecto actual.
Lo siguiente es realizarle el perfil al proyecto. Se puede enfocar de 3 modos: el uso de memoria, el uso de tiempo de CPU y la monitorización de la aplicación. Vamos a centrarnos en el uso de tiempo de CPU.

Resultados del perfil

profile_cpu

Análisis de los resultados

Echándole un vistazo a los resultados vemos que en general todas las funciones son llamadas alrededor de 350 veces y que las funciones tienen un tiempo de CPU bastante bajo, aunque los 3 hilos de ejecución están vivos durante el 100% del tiempo de ejecución.

La explicación a que vivan durante el 100% del tiempo y de ese número tan redondo de ejecuciones es que el programa en cuestión es un clon sencillo de Pacman, los hilos se ejecutan de principio a fin para controlar el programa y las 350 iteraciones son los movimientos que el personaje ha hecho recorriendo el mapeado para comerse las bolitas. Podemos ver también que de media se ha cambiado de dirección unas 20 veces y que en otras 40 el personaje se ha intentado mover a una posición no válida y se le ha dicho que siga por donde iba. Es curioso ver la información que se puede sacar de aquí. Desconozco sin embargo qué es el Self time, una visita a la página del plugin no me ha aclarado eso en particular, y la ayuda del plugin tampoco ofrece exactamente algo que me pueda orientar.

Pasando a lo interesante, vemos que dos funciones en particular consumen bastante tiempo de CPU, son las funciones inicializa() de Main y dibujaFondo() de la cola de eventos de la AWT.

En el caso de inicializa, podemos considerarla comprensible ya que se encarga de crear los objetos la primera vez que se ejecuta la aplicación y por eso puede tener una mayor carga que otras funciones más sencillas.

No obstante el caso de dibujaFondo() refleja perfectamente uno de los problemas a los que me enfrenté en el desarrollo, y es que al mover el personaje por el mapa, la pantalla dejaba reflejada la posición anterior del personaje y también la posición actual, con lo cual al final no se veían mas que pacmans por todas partes. Para solventar eso al final lo que hice fué emplear doblebuffering y repintar cada vez que el personaje se movía el mapa. Sin embargo, pensaba que el modo en el que lo había implementado era más rápido, ya que la primera vez tenía que crear el mapa a partir de un string de chars, y las siguientes se creaba a partir de la primera versión del mapa. Tal vez la copia del bitmap y el reemplazo en pantalla consuman aún demasiado tiempo.

Consideraciones

En vista de lo comentado en los análisis de resultados, hacer más rápida la función dibujaFondo() sería clave para acelerar la aplicación. Tal vez podría utilizarse un acercamiento más local, redibujando únicamente la posición que ha abandonado el personaje en lugar de todo el mapeado. Esto sería sencillo ya que simplemente consistiría en poner un espacio en blanco (negro según el color del mapa) en donde antes estaba el personaje (si había un punto ya se lo habrá comido).

Entradas relacionadas:

  1. Diseño y Evaluación de Configuraciones: Práctica 6
  2. Diseño y Evaluación de Configuraciones – Práctica 2
  3. Diseño y Evaluación de Configuraciones – Práctica 5
  4. Diseño y Evaluación de Configuraciones: Práctica Final
  5. Diseño y Evaluación de Configuraciones – Práctica 1

No hay comentarios :-(

¡Puedes ser el primero en dejar uno!

¡Haya paz!

  • Política de comentarios:
    No seas medalla.