2010-09-14 7 views
5

Los profilers con los que tengo experiencia (principalmente el generador de perfiles Mars D digital que viene con el compilador) parecen ralentizar masivamente la ejecución del programa que se está perfilando. Esto tiene un efecto importante en mi disposición a usar un generador de perfiles, ya que hace que la creación de perfiles sea una ejecución "real" de muchos de mis programas, en lugar de probar con una entrada muy pequeña, poco práctica. No sé mucho sobre cómo se implementan los perfiladores. ¿Es una ralentización importante (> 2x) cuando se trata de un perfil de la realidad, o hay perfiladores que lo evitan? Si se puede evitar, ¿hay perfiladores rápidos disponibles para D, preferiblemente para D2 y, preferiblemente, de forma gratuita?¿Todos los perfiladores reducen significativamente la ejecución?

Respuesta

15

No sé acerca de los perfiles D, pero en general hay dos formas diferentes en que un generador de perfiles puede recopilar información sobre el perfil.

El primero es por instrumentación, mediante la inyección de llamadas de registro en cualquier lugar. Esto ralentiza la aplicación más o menos. Típicamente más.

El segundo es el muestreo. Luego, el generador de perfiles rompe la aplicación a intervalos regulares e inspecciona la pila de llamadas. Esto no ralentiza la aplicación en absoluto.

La desventaja de un perfilador de muestreo es que el resultado no es tan detallado como con un perfilador de instrumentos.

Compruebe la documentación de su generador de perfiles si puede ejecutar con muestreo en lugar de instrumentación. De lo contrario, tiene algunos términos nuevos de Google en "muestreo" e "instrumentación".

+0

++ Sí, ¡reglas de muestreo! Pero no cualquier muestra anterior. Muestreo de la pila de llamadas, hora del reloj de pared e informe por línea (no función) del porcentaje de muestras que contienen esa línea. Y el detalle adicional que obtienes con la instrumentación es solo ruido de todos modos, si tu objetivo es encontrar un código que necesite optimizar. –

+0

Por esta razón, tiendo a preferir mucho los perfiles de muestreo siempre que sea práctico: tienden a proporcionar muchos datos confiables por un costo relativamente más bajo en rendimiento, y puedo ejecutarlo durante un tiempo prolongado para promediar los resultados de un proceso estocástico y ruidoso. (como una función que toma 1 ms el 90% del tiempo que se llama y 500 ms el otro 10%). – Crashworks

+0

Encontré el recuento exacto de llamadas de función que los perfiladores de instrumentos dan útil de vez en cuando. Si cargo 120 clientes en una lista, veo las funciones que se llaman 120 (y peor n x 120) veces. Entonces puedo encontrar funciones llamadas por error (es decir, desencadenadas por un evento). O llamadas hechas para cada elemento donde una llamada para todos ellos debería ser suficiente. –

1

Yo diría que sí, tanto las formas de muestreo como las de instrumentación de los perfiles impondrán un gran impacto en su programa, independientemente de a quién pertenezca el perfilador y en qué idioma.

+1

muchos perfiladores de muestreo pueden escalar con qué frecuencia toman sus muestras. Esto permite que la sobrecarga sea considerablemente menor que los perfiles de instrumentación (del orden del 1-5%). La calidad de los datos depende de la tasa de muestreo, por supuesto. Ambas formas de creación de perfiles tienen un impacto distinto de cero, pero el muestreo es significativamente menor. –

1

Puede probar el xfProf de h3r3tic, que es un generador de perfiles de muestreo. no han probado a mí mismo, pero ese tipo siempre hace cosas interesantes :)

partir de la descripción:

Si el programa se muestrea sólo unos pocos cientos (o miles) veces por segundo, el rendimiento por encima no será notable.

+0

Gracias. Esto debería ser una mejora (aún no lo ha probado), aunque todavía dice que necesita compilar sin optimizaciones, que probablemente tiene más de 2x perf. costo. – dsimcha

+0

@dsimcha: @torhu: Acabo de consultar el sitio de xfProf. Estoy triste. Está basado en los mismos principios que gprof. He aquí por qué me entristece: http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343 –

2

My favorite method of profiling ralentiza el programa manera de la manera abajo, y eso está bien. Ejecuto el programa bajo el depurador, con una carga realista, y luego lo interrumpo manualmente. Luego copio la pila de llamadas en algún lugar, como en el Bloc de notas. Por lo tanto, toma el orden de minutos para recoger una muestra. Entonces puedo reanudar la ejecución, o incluso está bien comenzar de nuevo desde el principio para obtener otra muestra.

Lo hago 10 o 20 veces, lo suficiente como para ver lo que el programa realmente está haciendo desde la perspectiva del reloj de pared. Cuando veo algo que aparece mucho, entonces tomo más muestras hasta que aparece nuevamente. Luego detuve y realmente estudio lo que está en el proceso de hacer y por qué, lo que puede tomar 10 minutos o más. Así es como descubro si esa actividad es algo que puedo reemplazar con un código más eficiente, es decir, no era totalmente necesario.

Mire, no estoy interesado en medir qué tan rápido o lento va. Puedo hacer eso por separado con tal vez solo un reloj.Estoy interesado en saber qué actividades toman un gran porcentaje de tiempo (no cantidad, porcentaje), y si algo toma un gran porcentaje de tiempo, esa es la probabilidad de que cada apilamiento lo vea.

Por "actividad" no necesariamente me refiero a dónde se cuelga la PC. En un software realista, la PC casi siempre está apagada en algún sistema o rutina de biblioteca en alguna parte. Por lo general, más importante es llamar a los sitios en nuestro código. Si veo, por ejemplo, una cadena de 3 llamadas que aparecen en la mitad de las muestras de la pila, eso representa una muy buena búsqueda, porque si alguno de ellos no es realmente necesario y puede eliminarse, el tiempo de ejecución disminuirá mitad.

Si quieres un gerente sonriente, solo hazlo una o dos veces.

Incluso en lo que se podría pensar que serían las aplicaciones matemáticas de cálculo matemático pesado donde se podría pensar que la optimización de bajo nivel y los hotspots dominarían el día, ¿sabes lo que a menudo encuentro? Las rutinas de la biblioteca matemática son verificando los argumentos, no crujiendo. A menudo, el código no está haciendo lo que crees que está haciendo, y no tienes que ejecutarlo a toda velocidad para descubrirlo.

+0

Menos útil cuando tienes un perfil bastante plano en el que ningún componente tarda más del 2% del tiempo de ejecución por sí mismo, pero de alguna manera tiene que bajar su lazo principal de 40ms a 33ms arreglando cincuenta cosas pequeñas. Pero ese es un caso bastante especializado. – Crashworks

+0

También debería echar un vistazo a los perfiladores de muestras modernos. Los sigo recomendando no porque creo que su método es pobre, sino porque estoy totalmente de acuerdo con su enfoque y estoy feliz de que haya herramientas automáticas que pueden hacerlo 1000 muestras por segundo. – Crashworks

+0

@Crashworks: gracias. Mi experiencia es que solo llegas al punto de tener pequeñas cosas pequeñas para optimizar después de un proceso de deshacerse de algunas cosas bastante masivas que nunca imaginaste que estaban allí. En cuanto a las herramientas, creo que Zoom y LTProf tienen la idea correcta, pero como he tratado de explicar antes, no necesitas una gran cantidad de muestras a menos que tus mayores problemas sean realmente muy pequeños. Además, no conozco ninguna herramienta que le permita examinar en detalle una muestra de pila representativa y el contexto del programa en vigor en el momento en que se tomó. Eso te da una idea de que los números no pueden. –

Cuestiones relacionadas