Il filtraggio delle classi per la profilazione della cpu funziona in Java VisualVM?

Question

Voglio filtrare quali classi sono state create in cpu in Java VisualVm (versione 1.7.0 b110325). Per questo, ho provato in Profiler -> Impostazioni -> Impostazioni CPU per impostare "Solo classi del profilo" al mio pacchetto sotto test, che non ha avuto alcun effetto. Poi ho cercato di sbarazzarmi di tutte le classi java. * E sun. * Impostandole in "Do not profile classes", che non ha avuto alcun effetto.

È semplicemente un errore? O mi sta sfuggendo qualcosa? C'è una soluzione? Voglio dire altro che:

• pagare per un profiler meglio
• facendo campionamento a mano (vedi One could use a profiler, but why not just halt the program?)
• passare alla visualizzazione delle chiamate albero, che non va bene in quanto solo la vista Profiler mi dà le percentuali di CPU consumata per metodo.

Voglio farlo principalmente per ottenere percentuali a metà strada corrette della CPU consumata per metodo. Per questo, ho bisogno di liberarmi delle misurazioni fastidiose, ad es. per sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (circa il 70%). Molti utenti sembrano avere questo problema, vedi ad es.

• 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

Il motivo per cui si visualizza sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() nel profilo è che è stata selezionata l'opzione Profilo nuovo Runnables selezionato.

Inoltre, se hai scattato un'istantanea della sessione di profilazione, potresti visualizzare l'intero callstack per qualsiasi metodo di hotspot: in questo modo puoi passare dal metodo run() ai metodi di logica dell'applicazione, filtrando il rumore generato dall'opzione Profilo nuovo Runnables.

Answer 2

OK, poiché il tuo obiettivo è far funzionare il codice il più velocemente possibile, lasciami suggerire come farlo. Non sono esperto di VisualVM, ma posso dirti cosa funziona. (Solo pochi profiler in realtà ti dicono che cosa avete bisogno di sapere, che è - che le linee del codice sono nella pila una frazione sano di tempo orologio a muro.)

L'unica misura che io abbia mai fastidio con è qualche cronometro sul tempo complessivo, o in alternativa, se il codice ha qualcosa come un framerate, il numero di fotogrammi al secondo. Non ho bisogno di alcun tipo di ulteriore interruzione di precisione, perché è nel migliore dei casi un indizio a distanza di quanto è tempo di perdere (e più spesso del tutto irrilevante), quando c'è un modo molto diretto per individuarlo.

Se non si desidera eseguire random-pausing, dipende da voi, ma ha dimostrato di funzionare, e here's an example of a 43x speedup.

Fondamentalmente, l'idea è di ottenere un (piccolo, come 10) numero di campioni di stack, presi a intervalli casuali dell'orologio. Ogni campione è costituito (ovviamente) da un elenco di siti di chiamata e, eventualmente, da un sito non di chiamata alla fine. (Se il campione è durante I/O o sospensione, terminerà con la chiamata di sistema, che va bene. Questo è quello che vuoi sapere.)

Se c'è un modo per velocizzare il tuo codice (e c'è quasi certamente), la vedrai come una linea di codice che appare su almeno uno dei campioni di pila. La probabilità che apparirà su un singolo campione è esattamente la stessa della frazione di tempo che usa. Quindi, se c'è un sito di chiamata o un'altra linea di codice che utilizza una buona quantità di tempo e si può evitare di eseguirlo, il tempo complessivo diminuirà di quella frazione.

Non conosco tutti i profiler, ma uno lo so che può dirvi che è Zoom. Altri potrebbero riuscire a farlo. Possono essere più spiffy, ma non funzionano più velocemente o meglio del metodo manuale quando lo scopo è massimizzare le prestazioni.