¿Las clases de filtrado para el perfil de CPU funcionan en Java VisualVM?

Question

Quiero filtrar qué clases están siendo perfiladas por CPU en Java VisualVm (Versión 1.7.0 b110325). Para esto, intenté en Profiler -> Configuración -> Configuración de CPU para establecer "Profile only classes" en mi paquete bajo prueba, que no tuvo ningún efecto. Luego traté de deshacerme de todas las clases java. * Y sun. * Configurándolas en "No perfil clases", que tampoco tuvieron ningún efecto.

¿Es esto simplemente un error? ¿O me estoy perdiendo algo? ¿Hay alguna solución? Quiero decir que no sea:

• pagar por un perfilador mejor
• hacer un muestreo con la mano (ver One could use a profiler, but why not just halt the program?)
• cambie a la vista de llamadas en árbol, que no es bueno ya que sólo la vista Profiler me da los porcentajes de la CPU consumida por método.

Quiero hacer esto principalmente para obtener porcentajes correctos a medias de la CPU consumida por método. Para esto, necesito deshacerme de las mediciones molestas, p. para sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (alrededor del 70%). Muchos usuarios parecen tener este problema, ver p.

• Java VisualVM giving bizarre results for CPU profiling - Has anyone else run into this?
• rmi.transport.tcp.tcptransport Connectionhandler consumes much CPU
• Can't see my own application methods in Java VisualVM.

Answer 1

La razón por la que ve sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() en el perfil es que dejó la opción Perfil nuevo Runnables seleccionado.

Además, si tomó una instantánea de su sesión de generación de perfiles, podría ver toda la lista de llamadas para cualquier método de zona activa: de esta manera podría navegar desde el método run() hasta sus propios métodos lógicos de aplicación, filtrando el ruido generado por el Perfil nuevo Runnables opción.

Answer 2

OK, ya que su objetivo es hacer que el código se ejecute lo más rápido posible, permítanme sugerir cómo hacerlo. No soy un experto en VisualVM, pero puedo decirte lo que funciona. (Sólo unos pocos perfiladores en realidad le dicen lo que necesita saber, que es - qué líneas de código en la pila una fracción saludable del tiempo del reloj de pared.)

La única medida que molestarse con es algunos cronómetros en el tiempo total, o alternativamente, si el código tiene algo así como una tasa de cuadros, el número de cuadros por segundo. No necesito ningún tipo de desglose de precisión adicional, porque en el mejor de los casos es una pista remota de lo que está perdiendo el tiempo (y más a menudo totalmente irrelevante), cuando hay una forma muy directa de localizarlo.

Si no quiere hacer random-pausing, depende de usted, pero está comprobado que funciona, y here's an example of a 43x speedup.

Básicamente, la idea es que obtienes un número (pequeño, como 10) de muestras de pila, tomadas aleatoriamente en el reloj de pared. Cada muestra consta (obviamente) de una lista de sitios de llamadas, y posiblemente un sitio que no es de llamadas al final. (Si la muestra está en E/S o en suspensión, terminará en la llamada al sistema, que es lo único que desea saber)

Si hay una forma de acelerar su código (y seguramente lo habrá), lo verá como una línea de código que aparece en al menos una de las muestras de la pila. La probabilidad de que aparezca en cualquier muestra es exactamente la misma que la fracción de tiempo que utiliza. Entonces, si hay un sitio de llamada u otra línea de código que utiliza una fracción de tiempo saludable, y puede evitar ejecutarlo, el tiempo total disminuirá en esa fracción.

No conozco todos los perfiles, pero uno que sé que puede decir que es Zoom. Otros pueden ser capaces de hacerlo. Pueden ser más interesantes, pero no funcionan más rápido o mejor que el método manual cuando su propósito es maximizar el rendimiento.