39 votos

Si el analizador no es la respuesta, ¿qué otras opciones tenemos?

Después de ver la presentación de "Ansiedad de Desempeño" de Joshua Bloch, he leído el documento que él propuso en la presentación de la "Evaluación de la Exactitud de Java Perfiladores". Citando a la conclusión:

Nuestros resultados son inquietantes, ya que indican que el analizador de incorrección es omnipresente-que ocurre en la mayoría de nuestros siete puntos de referencia y en dos de producción de la JVM-y significativo-los cuatro de el estado-of-the-art generadores de producir incorrecto perfiles. Incorrecta los perfiles pueden fácilmente causar un analista de rendimiento al pasar el tiempo la optimización de frío métodos que va a tener un efecto mínimo en el rendimiento. Se demuestra que una prueba de concepto de analizador, que no use el rendimiento los puntos de muestreo no sufre de los problemas anteriores

La conclusión del documento es que no podemos realmente creer que el resultado de los perfiladores. Pero entonces, ¿cuál es la alternativa de utilizar los perfiladores. Debemos ir hacia atrás y sólo utilizar nuestro sentimiento para hacer la optimización?

ACTUALIZACIÓN: UN punto que parece perderse en la discusión es el observador efecto. Podemos construir un analizador que realmente 'observador efecto'libre?

42voto

Mike Dunlavey Puntos 25419

Oh, hombre, ¿por dónde empezar?

En primer lugar, estoy sorprendido de que esto es una novedad. Segundo, el problema no es que los generadores sean malos, es que algunos de los perfiladores son malos. Los autores construyeron uno que sienten que es bueno, sólo por evitar algunos de los errores que encontraron en las que se evalúa. Los errores son comunes debido a algunos persistentes mitos acerca de la creación de perfiles de rendimiento.

Pero vamos a ser positivos. Si uno quiere encontrar oportunidades de speedup, es realmente muy simple:

  • El muestreo debe ser correlacionadas con el estado del programa.
    Eso significa que ocurre en un verdaderamente aleatorios de tiempo, independientemente de si el programa es en de e/S (excepto para la entrada de usuario), o en el GC, o en un apretado CPU bucle, o lo que sea.

  • El muestreo debe leer la pila de llamadas de función,
    con el fin de determinar que las declaraciones eran "activos" en el momento de la muestra. La razón es que cada sitio de llamada (punto en el que se llama a una función) tiene un porcentaje de coste igual a la fracción de tiempo que se está en la pila. (Nota: el documento se refiere en su totalidad con el tiempo, ignorando el enorme impacto de la evitables función de llamadas de software de gran tamaño. De hecho, la razón detrás de la original gprof fue para ayudar a encontrar esas llamadas.)

  • El informe debe mostrar por ciento por línea (no por la función).
    Si un "caliente" de la función se identifica, uno todavía tiene que cazar dentro de la "caliente" líneas de código de contabilidad para la época. Esa información está en las muestras! ¿Por qué ocultarlo?

Casi universal error (que el papel de las acciones) es para preocuparse demasiado con la exactitud de la medición, y no basta con la precisión de la ubicación. Por ejemplo, aquí es un ejemplo de la optimización del rendimiento en el cual una serie de problemas de rendimiento fueron identificados y se fija, lo que resulta en un speedup de 43 veces. No era esencial para conocer con precisión el tamaño de cada problema antes de corregir, pero para saber su ubicación. Un fenómeno de la optimización del rendimiento es que la fijación de un problema, reduciendo el tiempo, aumenta los porcentajes de los restantes problemas, por lo que son más fáciles de encontrar. Mientras cualquier problema encontrado y corregido, el progreso hacia el objetivo de encontrar y solucionar todos los problemas. No es esencial para fijarlos en orden decreciente según el tamaño, pero es esencial determinar.

Sobre el tema de la precisión estadística de la medición, si una llamada está en la pila algunos porcentaje de tiempo F (20%), y N (como 100) aleatorio de tiempo se toman las muestras, el número de ejemplos que muestran el punto de llamada es una distribución binomial con media = NF = 20, desviación estándar = sqrt(NF(1-F)) = sqrt(16) = 4. Así, el porcentaje de muestras que muestran será de 20% +/- 4%. Así es que precisa? En realidad no, pero el problema ha sido encontrado? Precisamente.

De hecho, el mayor problema es que, en términos de por ciento, el menor número de muestras necesarias para localizarlo. Por ejemplo, si 3 se toman las muestras, y un punto de llamada se muestra en 2 de ellos, es muy probable que sea muy costoso. (Específicamente, sigue una distribución beta. Si usted genera 4 uniforme de 0,1 números aleatorios, y ordenarlos, la distribución de la 3ª es la distribución de costos para que el punto de llamada. Es decir es(2+1)/(3+2) = 0.6, por lo que es el ahorro esperado, dadas esas muestras.) INSERTADO: Y el factor de aceleración que se obtiene es gobernado por otro la distribución, BetaPrime, y su promedio es de 4. Así que si toman 3 muestras, veo un problema en 2 de ellos, y eliminar ese problema, en promedio va a hacer el programa de cuatro veces más rápido.

Es tiempo ya de que los programadores sopló las telarañas de nuestras cabezas en el tema de generación de perfiles.

Descargo de responsabilidad - el papel de error para hacer referencia a mi artículo: Dunlavey, "optimización del Rendimiento con el nivel de instrucción de coste derivado de la pila de llamadas de muestreo", ACM SIGPLAN Avisos 42, 8 (agosto, 2007), pp 4-8.

8voto

Michael Borgwardt Puntos 181658

Si he leído bien, el papel sólo habla acerca de muestra basado en los perfiles. Muchos generadores de hacer también la instrumentación basada en perfiles. Es mucho más lento y tiene algunos otros problemas, pero no debe sufrir de los sesgos que el documento habla acerca de.

La conclusión del documento es que nos no creen realmente en el resultado de los perfiladores. Pero entonces, ¿cuál es la alternativa de utilizar los perfiladores.

No. La conclusión del documento es que los actuales generadores de' métodos de medición han defectos específicos. Ellos proponen una solución. El papel es bastante reciente. Yo esperaría que los perfiladores para implementar esta revisión con el tiempo. Hasta entonces, incluso un defectuoso profiler es todavía mucho mejor que el "sentimiento".

3voto

Andrew White Puntos 23508

A menos que usted está construyendo filo de las aplicaciones que necesitan cada ciclo de CPU, a continuación, he encontrado que los perfiladores son una buena manera para encontrar que el 10% más lento partes de su código. Como desarrollador, yo diría que debe ser todo lo que realmente importa en casi todos los casos.

Tengo experiencia con http://www.dynatrace.com/en/ y puedo decir que es muy bueno en la búsqueda de la fruta que cuelga baja.

Los perfiladores son como cualquier otra herramienta, y tienen sus peculiaridades, pero me gustaría confiar en ellos encima de un ser humano, cualquier día para encontrar los puntos calientes en su aplicación a la vista.

-1voto

darioo Puntos 23903

Si usted no confía en los perfiladores, entonces usted puede ir en la paranoia el modo mediante el uso de programación orientada a aspectos, envolver alrededor de cada método en la aplicación y, a continuación, utilizando un registrador para registrar cada invocación del método.

La aplicación va muy lento, pero al menos tendrás un preciso recuento del número de veces que cada método se invoca. Si también quieres ver la duración de cada método se lleva a ejecutar, envoltura alrededor de cada método perf4j.

Después de volcar todas estas estadísticas para archivos de texto, uso de algunas herramientas para extraer toda la información necesaria y, a continuación, visualizar. Me imagino que esto le dará una buena visión general de lo lento que su aplicación se encuentra en ciertos lugares.

-3voto

Oldpond Puntos 17

En realidad, usted es mejor de los perfiles a nivel de base de datos. La mayoría de las bases de datos empresariales vienen con la capacidad de mostrar las primeras consultas durante un período de tiempo. Empezar a trabajar en las consultas hasta que el de arriba está abajo a 300 ms o menos, y se han hecho grandes progresos. Los perfiladores son útiles para mostrar el comportamiento de la pila y para la identificación de los subprocesos bloqueados, pero yo personalmente nunca lo he tenido mucha tracción con los equipos de desarrollo en la identificación de métodos u objetos de gran tamaño.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X