Programa de creación de perfiles por tipo de actividad

Question

La salida de un generador de perfiles típico es una lista de funciones en su código, ordenadas por la cantidad de tiempo que cada función tomó mientras se ejecutaba el programa.

Esto es muy bueno, pero a veces me interesa más lo que estaba haciendo el programa la mayor parte del tiempo, que con dónde estaba EIP la mayor parte del tiempo.

Un ejemplo de salida de mi perfilador hipotético es:

Waiting for file IO - 19% of execution time. 
Waiting for network - 4% of execution time 
Cache misses  - 70% of execution time. 
Actual computation - 7% of execution time. 

¿Hay un generador de perfiles tales? ¿Es posible derivar tal salida de un perfilador "estándar"?

Estoy usando Linux, pero estaré encantado de escuchar cualquier solución para otros sistemas.

Answer 1

Esto es solo Solaris, pero dtrace puede monitorear casi todo tipo de E/S, CPU con conexión/desconexión, tiempo en funciones específicas, tiempo de inactividad, etc. No estoy seguro de si puede determinar errores de caché, suponiendo te refieres a la memoria caché de la CPU: no estoy seguro de si esa información está disponible o no por la CPU.

Answer 2

Por favor, eche un vistazo a at this y this.

Considera cualquier hilo. En cualquier momento, está haciendo algo, y lo está haciendo por una razón, y la lentitud se puede definir como el tiempo que se gasta por razones pobres: no es necesario que dedique ese tiempo.

Tome una instantánea del hilo en un punto en el tiempo. Tal vez se trata de un error de caché, en una instrucción, en una declaración, en una función, llamada desde una instrucción de llamada en otra función, llamada desde otra, y así sucesivamente, hasta call _main. Cada uno de esos pasos tiene una razón, que revela un examen del código.

1. Si alguno de esos pasos no es una buena razón y podría evitarse, ese instante de tiempo no necesita ser gastado.

Tal vez en ese momento el disco está llegando a cierto sector, por lo que se puede iniciar la transmisión de datos para llenar un búfer para que se pueda cumplir una instrucción de lectura en una función y esa función llamado desde un sitio de llamada en otra función, y desde otro, y así sucesivamente, hasta call _main, o lo que sea que sea la parte superior del hilo.

1. Repetir punto anterior 1.

Por lo tanto, el camino para encontrar los cuellos de botella es encontrar cuando el código es pasar el tiempo por razones pobres, y la mejor manera de descubrir que es para tomar instantáneas de su estado. El EIP, o cualquier otra parte pequeña del estado, no va a hacerlo, porque no le dirá por qué.

Muy pocos perfiladores "lo consiguen". Los que sí lo hacen son los muestreadores de pila del reloj de pared que informan por línea de código (no por función) porcentaje de tiempo activo (no cantidad de tiempo, especialmente no como tiempo "propio" o "exclusivo"). eso es Zoom, y hay otros.

Ver dónde se cuelga el EIP es como intentar decir la hora en un reloj con solo una segunda mano. Medir funciones es como intentar decir la hora en un reloj con algunos de los dígitos faltantes.Perfilar solo durante el tiempo de CPU, no durante el tiempo bloqueado, es como intentar decir la hora en un reloj que deja de funcionar aleatoriamente durante largos periodos. Preocuparse por la precisión de la medición es como tratar de programar su hora de almuerzo a la segunda.

Esto no es un tema misterioso.