Hay más de una manera de hacer eso.
Don't forget the no-profiler method.
La mayoría de los perfiladores asumen que necesita 1) de alta precisión estadística de tiempo (un montón de muestras), y 2) la baja precisión de la identificación del problema (funciones & call-gráficos).
Esas prioridades se pueden revertir. Es decir. el problema puede ubicarse en la dirección precisa de la máquina, mientras que la precisión en el costo es una función del número de muestras.
La mayoría de los problemas reales cuestan al menos 10%, donde la alta precisión no es esencial.
Ejemplo: Si algo está haciendo que su programa tome el doble de tiempo que debería, eso significa que hay un código que cuesta el 50%. Si toma 10 muestras de la pila de llamadas mientras está lenta, las líneas precisas de código estarán presentes en aproximadamente 5 de ellas. Cuanto más grande es el programa, más probable es que el problema sea una llamada de función en algún lugar de la mitad de la pila.
Es contra intuitivo, lo sé.
NOTA: xPerf está casi allí, pero no del todo (por lo que puedo decir). Toma muestras de la pila de llamadas y las guarda; eso es bueno. Esto es lo que creo que necesita:
Solo debe tomar muestras cuando las desee. Tal como están las cosas, debes filtrar las irrelevantes.
En la vista de la pila debe mostrar las líneas o direcciones específicas en las que tienen lugar las llamadas, no solo las funciones completas. (Tal vez puede hacer esto, no podría decirlo desde el blog.)
Si hace clic para obtener la vista de mariposa, centrada en una sola instrucción de llamada o instrucción de hoja, debería mostrarle no la fracción de CPU, sino la fracción de muestras de pila que contiene esa instrucción. Esa sería una medida directa del costo de esa instrucción, como una fracción de tiempo. (Tal vez puede hacer esto, no podría decirlo). Entonces, por ejemplo, incluso si una instrucción fuera una llamada al archivo abierto u otra cosa que ralentiza el hilo, aún le cuesta tiempo al reloj de pared, y necesita saber que.
NOTA: Acabo de revisar a Luke Stackwalker, y se aplican las mismas observaciones. Creo que está en el camino correcto, pero necesita un trabajo de IU.
AGREGADO: Después de haber examinado a LukeStackwalker con más cuidado, me temo que es víctima de la suposición de que la medición de funciones es más importante que la localización de enunciados. Entonces, en cada muestra de la pila de llamadas, actualiza la información de sincronización del nivel de función, pero todo lo que hace con la información del número de línea es realizar un seguimiento de los números de línea máximos y mínimos en cada función, que, cuantas más muestras tome, más alejados se ponen. Por lo tanto, básicamente descarta la información más importante: la información del número de línea. La razón por la que es importante es que si decide optimizar una función, necesita saber qué líneas necesitan funcionar, y esas líneas estaban en las muestras de la pila (antes de que fueran descartadas).
Uno podría objetar que si la información del número de línea se conservara se agotaría rápidamente. Dos respuestas 1) Solo hay tantas líneas que aparecen en las muestras y aparecen repetidamente. 2) No se necesitan tantas muestras, siempre se ha asumido la suposición de que es necesaria una alta precisión estadística de medición, pero nunca se justifica.
Sospecho que otros muestrarios de pila, como xPerf, tienen problemas similares.
¿Qué plataforma? Yo uso gprof cuando estoy trabajando con g ++ en Linux. –
Mi programa se ejecuta en Windows XP. – stanigator