Il benchmarking del cronometro è accettabile?

Question

Qualcuno usa mai il benchmarking del cronometro o dovrebbe sempre essere usato uno strumento di performance? Esistono buoni strumenti gratuiti disponibili per Java? Quali strumenti usi?

Per chiarire le mie preoccupazioni, il benchmarking del cronometro è soggetto a errori dovuti alla pianificazione del sistema operativo. In una determinata esecuzione del programma, il sistema operativo potrebbe pianificare un altro processo (o più) nel mezzo della funzione che stai programmando. In Java, le cose vanno ancora un po 'peggio se stai cercando di cronometrare un'applicazione thread, poiché lo scheduler JVM lancia un po' più di casualità nel mix.

Come si affronta la pianificazione del sistema operativo durante il benchmarking?

Answer 1

Il benchmarking del cronometro va bene, a condizione che si misurino abbastanza iterazioni per essere significative. In genere, ho bisogno di un tempo totale trascorso di un numero di secondi a cifra singola. Altrimenti, i risultati sono facilmente distorti in modo significativo dalla pianificazione e da altre interruzioni di O / S nel processo.

Per questo utilizzo un piccolo set di metodi statici che ho sviluppato molto tempo fa, basati su System.currentTimeMillis () .

Per il lavoro di profilazione ho usato jProfiler per un numero di anni e l'ho trovato molto buono. Di recente ho esaminato YourKit , che sembra fantastico dal sito Web, ma non l'ho usato affatto , personalmente.

Per rispondere alla domanda sulle interruzioni della pianificazione, trovo che eseguire ripetute esecuzioni fino a quando non si ottengono consistenza / osservi i lavori nella pratica per eliminare risultati anomali dalla pianificazione dei processi. Trovo anche che la pianificazione dei thread non abbia alcun impatto pratico per le esecuzioni tra 5 e 30 secondi. Infine, dopo aver superato i pochi secondi, la pianificazione della soglia ha, nella mia esperienza, un impatto trascurabile sui risultati: trovo che una corsa di 5 secondi abbia una media costante della stessa di una corsa di 5 minuti per tempo / iterazione.

Potresti anche prendere in considerazione la pre-elaborazione del codice testato circa 10.000 volte per "riscaldare". JIT, a seconda del numero di volte in cui prevedi che il codice testato venga eseguito nel tempo nella vita reale.

Answer 2

È totalmente valido finché si misurano intervalli di tempo sufficientemente ampi. Eseguirò 20-30 corse di ciò che intendi testare in modo che il tempo totale trascorso sia superiore a 1 secondo. Ho notato che i calcoli del tempo basati su System.currentTimeMillis () tendono a essere 0ms o ~ 30ms; Non penso che tu possa ottenere qualcosa di più preciso di così. Puoi provare System.nanoTime () se devi davvero misurare un piccolo intervallo di tempo:

• documentazione: http: / /java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime ()
• COSÌ domanda sulla misurazione di piccoli intervalli di tempo, poiché anche System.nanoTime () presenta alcuni problemi: Come posso misurare il tempo con il microsecondo precisione in Java?

Answer 3

Un profiler ti fornisce informazioni più dettagliate, che possono aiutare a diagnosticare e risolvere problemi di prestazioni.

In termini di misurazione effettiva, il tempo del cronometro è ciò che gli utenti notano, quindi se si desidera confermare che le cose sono entro limiti accettabili, il tempo del cronometro va bene.

Quando vuoi effettivamente risolvere i problemi, tuttavia, un profiler può essere davvero utile.

Answer 4

Il cronometro è in realtà il miglior punto di riferimento!

Il vero tempo di risposta dell'utente finale è il tempo che conta davvero.

Non è sempre possibile ottenere questo tempo utilizzando gli strumenti disponibili, ad esempio la maggior parte degli strumenti di test non include il tempo impiegato da un browser per eseguire il rendering di una pagina, quindi una pagina supercomplex con css scritti male mostrerà tempi di risposta inferiori al secondo agli strumenti di test, ma, 5 secondi più il tempo di risposta per l'utente.

Gli strumenti sono ottimi per i test automatizzati e per la determinazione dei problemi, ma non perdete di vista ciò che volete davvero misurare.

Answer 5

Devi testare un numero realistico di iterazioni in quanto otterrai risposte diverse a seconda di come testi il ??tempismo. Se si esegue un'operazione solo una volta, potrebbe essere fuorviante prendere la media di molte iterazioni. Se vuoi sapere il tempo necessario al riscaldamento della JVM, potresti eseguire molte (ad esempio 10.000) iterazioni che non sono incluse nei tempi.

Ti suggerisco anche di usare System.nanoTime () poiché è molto più preciso. Se il tempo del test è di circa 10 micro-secondi o meno, non si desidera chiamarlo troppo spesso o può cambiare il risultato. (ad es. se sto testando per 5 secondi e voglio sapere quando è attivo ottengo solo nanoTime ogni 1000 iterazioni, se so che un'iterazione è molto veloce)

Answer 6

  

Come si affronta la pianificazione del sistema operativo durante il benchmarking?

Indice di riferimento per abbastanza a lungo su un sistema che è rappresentativo della macchina che verrà utilizzata. Se il tuo sistema operativo rallenta l'applicazione, questo dovrebbe far parte del risultato.

Non ha senso dire che il mio programma sarebbe più veloce, se solo non avessi un sistema operativo.

Se stai usando Linux , puoi usare strumenti come numactl , chrt e tasket per controllare come vengono utilizzate le CPU e la pianificazione.

Answer 7

I profilatori possono interferire con i tempi, quindi vorrei utilizzare una combinazione di tempi del cronometro per identificare i problemi di prestazioni generali, quindi utilizzare il profiler per capire dove viene impiegato il tempo. Ripeti il ??processo come richiesto.

Answer 8

Dopotutto, è probabilmente la seconda forma di benchmarking più popolare, subito dopo il benchmarking no-watch " - dove diciamo "questa attività sembra lenta, quella che sembra veloce."

Di solito, ciò che è più importante ottimizzare è ciò che interferisce con l'esperienza dell'utente, che è spesso una funzione della frequenza con cui si esegue l'azione e qualsiasi altra cosa accada contemporaneamente. Altre forme di benchmarking spesso aiutano a concentrarsi su di esse.

Answer 9

Penso che una domanda chiave sia la complessità e la durata dell'intervento.

A volte utilizzo persino le misurazioni del cronometro fisico per vedere se qualcosa richiede minuti, ore, giorni o persino settimane per calcolare (sto lavorando con un'applicazione in cui i tempi di esecuzione negli ordini di diversi giorni non sono inauditi, anche se secondi e i minuti sono gli intervalli di tempo più comuni).

Tuttavia, l'automazione offerta dalle chiamate a qualsiasi tipo di sistema di clock sul computer, come la chiamata java millis a cui si fa riferimento nell'articolo collegato, è chiaramente superiore al vedere manualmente per quanto tempo dura qualcosa.

I profiler sono carini, quando funzionano, ma ho avuto problemi ad applicarli alla nostra applicazione, che di solito comporta la generazione di codice dinamico, il caricamento dinamico di DLL e il lavoro svolto nei due compilati just-in-time-compilati linguaggi di scripting della mia applicazione. Spesso si limitano ad assumere un unico linguaggio di origine e altre aspettative non realistiche per software complessi.

Answer 10

Oggi ho eseguito un programma che ha cercato e raccolto informazioni da un mucchio di file dBase, ci sono voluti poco più di un'ora per l'esecuzione. Ho dato un'occhiata al codice, ho fatto un'ipotesi su quale fosse il collo di bottiglia, ho apportato un lieve miglioramento all'algoritmo e ho rieseguito il programma, questa volta completato in 2,5 minuti .

Non avevo bisogno di alcuno strumento di profilazione o suite di benchmark per dirmi che la nuova versione rappresentava un miglioramento significativo. Se avessi avuto bisogno di ottimizzare ulteriormente il tempo di esecuzione probabilmente avrei fatto qualche analisi più sofisticata ma questo non era necessario. Trovo che questo tipo di "benchmarking del cronometro" è una soluzione accettabile in numerosi casi e il ricorso a strumenti più avanzati in realtà richiederebbe più tempo in questi casi.

Answer 11

Non credo che il benchmarking del cronometro sia troppo orribile, ma se riesci ad accedere a una macchina Solaris o OS X dovresti dare un'occhiata a DTrace. L'ho usato per ottenere grandi informazioni sui tempi nelle mie applicazioni.

Answer 12

Uso sempre il benchmarking del cronometro in quanto è molto più semplice. I risultati non devono essere molto precisi per me. Se hai bisogno di risultati accurati, non dovresti utilizzare il benchmarking del cronometro.

Answer 13

Lo faccio sempre. Preferirei di gran lunga usare un profiler, ma il fornitore della lingua specifica del dominio con cui sto lavorando non ne fornisce uno.