È in esecuzione "milli": i marchi sono una buona idea?

Uno dei motivi per usare il calibro invece di scrivere solo in modo univoco il proprio codice di benchmarking è che il calibro fa molto per evitare alcune delle insidie della scrittura di micro-benchmark. Ad esempio, un buon benchmark dovrebbe prima eseguire il codice in una fase di riscaldamento che assicuri che tutto il codice rilevante venga JIT. Dovrebbe anche garantire che fare il doppio delle iterazioni richieda il doppio del tempo; in caso contrario, suggerisce che la JVM sta ottimizzando il lavoro.

Tutto ciò significa che per eseguire correttamente il benchmark del codice, il calibro deve eseguire lotti di iterazioni. Per un'attività che dovrebbe richiedere qualcosa dell'ordine di microsecondi, questo è ragionevole. Ma se una singola iterazione impiegherà più di 10 secondi, ciò significa che la corsa del calibro richiederà davvero molto tempo. La mia ipotesi è che il team di Caliper abbia deciso che, a causa di questo, un compito che richiede più di 10 secondi di esecuzione era molto più probabile che fosse il risultato dell'errore del programmatore rispetto a una scelta intenzionale di scrivere un benchmark che avrebbe impiegato ore per essere eseguito. Effettuando il pagamento anticipato, aiuta i programmatori a capire rapidamente che è necessario correggere un bug, piuttosto che far girare la macchina per ore.

Un'idea con un design basato sui test consiste nell'eseguire tutti i test delle unità durante la creazione di un progetto, che consente di rilevare rapidamente le regressioni funzionali prima di commettere le modifiche che le hanno provocate. Affinché ciò funzioni, tutti i test devono essere completati rapidamente.

Se i tuoi benchmark sono eseguiti rapidamente, possono essere inclusi nel tuo framework di test (non so se questo è ciò che dovrebbe essere per Caliper, ma Google è pesantemente in TDD ...). In ogni caso, l'intero punto di aggiungere benchmark all'infrastruttura basata sui test sarebbe quello di rilevare rapidamente le principali regressioni delle prestazioni, quindi, per quel tipo di utilizzo, dovresti vuoi per contrassegnare l'intervallo troppo lungo come errore.

Molti rallentamenti del codice si verificano in piccoli cicli stretti. Se sai che il tuo tempo è trascorso, un micro-benchmark può aiutarti a ottimizzare solo quel piccolo pezzetto di codice.

I test unitari devono essere completati in un ragionevole lasso di tempo. È davvero raro per me scrivere un test unitario che impiega più di un secondo o due per eseguirlo, dal momento che potrei avere due o trecento test di questo tipo o più in un assemblaggio di test.