Linux muestra el tiempo de perfiles

Question

versión corta basada en:

¿Hay un buen perfilador de muestreo basado en el tiempo para Linux?

versión larga:

Yo generalmente uso OProfile para optimizar mis aplicaciones. Recientemente encontré una deficiencia que me tiene preguntando.

El problema era un ciclo cerrado, desove C++ filt para exigir un nombre de C++. Solo me encontré con el código accidentalmente mientras buscaba otro cuello de botella. El OProfile no mostró nada inusual sobre el código, así que casi lo ignoré, pero mi sentido del código me indicó que optimice la llamada y vea qué sucedió. Cambié el popen de C++ filt a abi::__cxa_demangle. El tiempo de ejecución pasó de más de un minuto a un poco más de un segundo. Aproximadamente una velocidad de x60.

¿Hay alguna manera en que podría haber configurado OProfile para marcar la llamada popen? Como los datos del perfil se encuentran ahora OProfile cree que el cuello de la botella fue el montón y std::string llamadas (que BTW una vez optimizado redujo el tiempo de ejecución a menos de un segundo, más de x2 de velocidad).

Aquí está mi configuración Oprofile:

$ sudo opcontrol --status 
Daemon not running 
Event 0: CPU_CLK_UNHALTED:90000:0:1:1 
Separate options: library 
vmlinux file: none 
Image filter: /path/to/executable 
Call-graph depth: 7 
Buffer size: 65536 

¿Hay otro perfilador para Linux que podría haber encontrado el cuello de botella?

Sospecho que el problema es que OProfile solo registra sus muestras en el proceso en ejecución. Me gustaría que siempre registre sus muestras en el proceso que estoy perfilando. Entonces, si el proceso está actualmente desactivado (bloqueo en IO o una llamada popen) OProfile simplemente colocaría su muestra en la llamada bloqueada.

Si no puedo solucionar esto, OProfile solo será útil cuando el ejecutable esté cerca del 100% de la CPU. No puede ayudar con ejecutables que tienen llamadas de bloqueo ineficientes.

Answer 1

Me alegro de que haya preguntado. Creo que se puede hacer que OProfile haga lo que yo considero correcto, que es tomar muestras de la pila en el reloj de pared con el tiempo cuando el programa está siendo lento y, si no le permite examinar muestras individuales de la pila, al menos Haga un resumen de cada línea de código que aparece en las muestras, el porcentaje de muestras en las que aparece la línea. Esa es una medida directa de lo que se ahorraría si esa línea no estuviera allí. Here's one discussion.Here's another, y another. Y, como dijo Paul, Zoom debería hacerlo.

Si su tiempo pasó de 60 segundos a 1 segundo, eso implica que cada muestra de pila tendría una probabilidad 59/60 de mostrarle el problema.

Answer 2

Probar Zoom - Creo que le permitirá perfilar todos los procesos - sería interesante saber si en este caso resalta su problema.

Answer 3

hackeado rápidamente hasta perfilador de muestreo trivial para Linux: http://vi-server.org/vi/simple_sampling_profiler.html

anexa backtrace(3) a un archivo en SIGUSR1, y luego se convierte en fuente anotada.

Answer 4

escribí esto hace mucho tiempo, sólo porque no podía encontrar nada mejor: https://github.com/dicej/profile

acabo de encontrar esto, también, aunque no lo he probado: https://github.com/oliver/ptrace-sampler