\subsubsection{Profiling} 
\label{sub:profiling}

%http://docs.sun.com/app/docs/doc/802-5696/6i9egm606?l=es&a=view
%prof--Generate the Profile of a Program  page 2
%gprof--Generate a Call Graph Profile  page 4
%tcov--Statement-Level Analysis  page 7
%tcov Enhanced--Statement-level Analysis  page 13
%Profile Feedback  page 16

Un profiler es una herramienta que calcula el comportamiento de la ejecución de un programa.
El resultado obtenido no se limita al tiempo de ejecución, si no que devuelve valores referentes a llamadas a función, accesos a cache, fallos de lectura/escritura,etc.
La salida es o bien un log donde se registran todos los eventos acontecidos o bien un sumario estadístico de los eventos observados.
Los profilers tienen una amplia gama de técnicas para tomar los datos, incluyendo interrupciones, instrumentación de código, {\it hooks}.

Un ejemplo de profilers  son {\it prof} y {\it gprof}.
Ambos están disponibles para la mayoría de sistemas Unix y el resultado se crea a partir del tiempo de CPU.
tanto {\it prof} como {\it gprof} crean las estadísticas interrumpiendo la ejecución del programa a partir de intervalos periódicos y relacionando la dirección de interrupción con el procedimiento.
Con esta forma de cálculo, el resultado obtenido se aproxima al tiempo que realmente se requiere para realizar el proceso.
Que únicamente sea una aproximación se debe a que puede haber alteraciones de fase, lo que implica que el tiempo de ejecución calculado sea desproporcional.
La diferencia principal entre estos dos profilers es que {\it gprof} crea un grafo de llamadas para indicar la procedencia de todas las llamadas realizadas mientras que {\it prof} no tiene en cuenta la procedencia de las llamadas de las funciones y se limita a evaluar cada procedimiento de manera independiente.
Para nuestro proyecto, esta diferencia hace que {\it gprof} se acerque más al objetivo que buscamos, ya que, al parsear el profiler para calcular la eficiencia, necesitamos poder crear un grafo de llamadas, para averiguar qué llamada concreta es la que nos interesa. Si, por ejemplo, tenemos 5 tests de eficiencia y todos llaman una vez a una misma función, si no sabemos quien es el emisor de cada una de las llamadas, será imposible calcular el resultado para cada uno de los tests. 

Un problema de los dos profilers anteriormente comentados es que no tenían en cuenta el número de programas ejecuntándose en el momento del profiling.
Para este problema, {\it tprof} ofrece una solución parcial.
El report creado mediante la ejecución de {\it tprof}, a parte de mostrar las características referentes al proceso evaluado, también muestra el listado de procesos externos que estaban ejecutándose en paralelo al programa evaluado.
Nuestro interés es poder independizar el tiempo de ejecución de todo factor externo y {\it tprof} no llega tan lejos, ya que al evaluar el proceso, el resultado  es dependiente de estos factores.
Sin embargo, es un primer paso poder tener conciencia de los otros procesos que se están ejecutando debido a que permite delimitar el margen de error del resultado obtenido.

Otro problema tanto de {\it prof} como de {\it gprof} es que no realizan comparaciones estadísticas con ejecuciones anteriores, con lo cual, no se puede saber el progreso de eficiencia del código.
Una herramienta que soluciona en parte este problema es {\it xprofiler}.%

{\it xprofiler} es un profiler basado en {\it gprof} con la característica adicional de mostrar los resultados gráficamentemediante en {\it X Windows}.
El gráfico es un árbol en el que se muestra una relación entre los diferentes reports realizados.
Lo interesante de esta herramienta es el hecho de poder ver a partir de gráficas una evolución de los diferentes reports creados, ya que, de esta manera se puede observar como han afectado los cambios en el código a la eficiencia de éste.
El objetivo de {\it xprofiler} es, al igual que el de nuestro proyecto, mostrar al usuario el progreso de eficiencia de un proceso concreto.
Como podemos ver en la imagen \ref{fig:xprof}, el problema que tiene su interfaz gráfica puede llegar a ser muy compleja, algo que nosotros debemos evitar en nuestro proyecto.

\begin{figure}[!ht] 
	\centering
	\fbox{\pdfimage width 6in {Imagenes/xprof.png}}
	\caption{Screenshot de la herramienta Xprofiler} 
	\label{fig:xprof}
\end{figure} 

como hemos podido ver en este apartado, los profilers nos aportan varias ventajas.
Por un lado, nos soluciona el problema de granularidad ya que, mientras en las herramientas cronometradas el resultado era global, con los profilers el resultado se desgrana y se obtiene información de cada una de las funciones,
con lo cual, sabremos qué factores son los que ralentizan la ejecución y cuáles son los más eficientes.
Sin embargo, el problema de las dependencias sigue vigente y, aunque el cálculo del tiempo sea más fiable que con los métodos cronometrados \ref{sub:cronometrados}, la ejecución sigue dependiendo de factores referentes tanto al software (programas en ejecución paralela, sistema operativo,...) como al hardware (velocidad y arquitectura de la CPU, tipo de cache,...).

En conclusión, con una herramienta de profiling cubrimos la premisa de granularidad pero todavía persiste el problema de comparabilidad de resultados.
La solución que proponemos para evitar las dependencias externas a la ejecución es simular un escenario a partir del cual podamos independizar la medición de la eficiencia de factores como el tipo de arquitectura del procesador, su velocidad o el tipo de cache entre otras.














